Address non-ASCII filename support for files, audio, etc.

[trrwilson]

Fixes #72.

The library's multipart/form-data implementation uses custom logic to bypass the use of the filename* Content-Disposition parameter, which is RFC 6266's method of encoding non-ASCII filenames in multipart/form-data requests. This bypass was made in deference to an interpretation of RFC 7578 wherein the use of filename* is disallowed.

This PR removes the restriction by directly using System.Net.Http.MultipartFormDataContent.Add()'s filename* behavior.

Although pending discussion with the Base Common Library team is still needed to clarify best interoperability practices, this is a better current state because:

• It aligns with the existing language type in System.Net.Http
• The interpretation of the competing RFC is ambiguous; it appears it may not be making a statement about the filename* parameter itself, but rather on the use of the encoding scheme of the newer filename* in the older filename
• Most importantly, it fixes the readily observable issue against the OpenAI V1 endpoint -- and still leaves the older filename intact for any unanticipated backwards compatibility issues with API gateways or other intermediaries