Add RequestContent to azure-core

[alzimmermsft]

Create a new model class RequestContent which is capable of wrapping numerous request body types, such as ByteBuffer, InputStream, File/Path, etc, and providing a single interface for writing the contents over the wire. The purpose of this new type is the following:

Reducing API complexity

First, and foremost, RequestContent is expected to simplify the numerous potential solutions of sending a request body over the network. At this time, Flux<ByteBuffer> is the primary vessel for sending network request bodies, this type has limitations where disparate body types such as byte[], String, serializable objects, InputStream, etc need to be converted into a Flux<ByteBuffer>. This has resulted in both duplication of functionality for converting body contents into Flux<ByteBuffer> and difficulties in using Flux<ByteBuffer> APIs as not everyone is well versed in Reactor and asynchronous Java programming.

RequestContent's aim here is to simplify this into using a single interface which is able to abstract any conversions of request body types into what needs to be used to send network request bodies. This change is similar to what BinaryData has done for simplify API inputs and outputs into a single wrapping interface which can translate content into what user wants to consume it as or into how the user wants to provide it as input.

Less content copying

Next, RequestContent is expected to be used to reduce the copying of memory or loading disk contents into memory. Inherently, Flux<ByteBuffer> is almost always used as an in-memory representation, normally with ByteBuffer.wrap(byte[]). For certain request body types such as String, InputStream, File/Path, and serializable object the content is converted from that initial type into a byte[] and then wrapped by a ByteBuffer. This results in the content being store multiple times in different formats in memory, resulting in a much higher overhead than expected.

RequestContent's aim here is to maintain the base request body type for as long as possible until sending it over the network as the request body. And in some cases, such as File/Path and potentially InputStream, completely remove the need to load the content into memory, or loading the entire content into memory, and just write it directly to the network. Overall, this should reduce not only peak but general memory consumption when sending network requests.