Support File for multipart/form data in RLC

[MaryGao]

fixes #2176 and #2196 and #2200

The pr would cover the followings:

• Multipart/form-data support
  • Translate bytes to | string | Uint8Array | ReadableStream<Uint8Array> | NodeJS.ReadableStream | File
  • Export createFile, createFileFromStream and relevant options from @azure/core-rest-pipeline
  • Integrate cadl-ranch cases
• Refactor media types code
• Handle bytes according to content types

Please note below issues are NOT covered in this pr:

• Support multipart/form-data for Modular #2279
• Support the corner cases for bytes within different content types #2278
• Handle other multipart and form content types not multipart/form-data #2277
• Handle bytes in response body #2276
• Resolve duplications for union type | in getSchemaForType #2273

[joheredi]

Looks good, the only question I have is around bytes generating string instead of uint8array

[MaryGao]

Looks good, the only question I have is around bytes generating string instead of uint8array

@joheredi The pr implementation is to have a white list to translate bytes to binary/file/string according to encode/content-type context. For unrecognized cases it would go to default logic as string not uint8array.

This would be debatable. First I would be more caring about the existence possibility of these unrecognized cases so I created issues to figure out them(#2278 and #2276); Secondly if the default type is uint8Array I am not sure the core logic is correct(https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/core/core-client-rest/src/sendRequest.ts#L145) and setting as string would require customers to handle encode and may work around from e2e side.

So I prefer to have string then to keep collecting the real cases. How do you think?

[MaryGao]

@joheredi @qiaozha I plan to merge this pr and let me know if any further concern!