Cosmos: Allow specifying a different async runtime or HTTP transport

We tightly control the async runtime and HTTP transport, because we have latency and availability guarantees that depend on stable and consistent transport behaviour. However, we know some customers still need to run the Cosmos DB SDK in environments that require an alternate async runtime and/or HTTP transport layer.

So, we will provide a compile-time feature flag `nosupport_pluggable_runtime` which enables new APIs on `CosmosRuntimeBuilder` to allow configuring a custom Async Runtime (to replace tokio) and HTTP transport (to replace reqwest). Calling either of these APIs will apply a marker to diagnostic strings and the user-agent to make clear that this is a configuration that is not eligible for the standard Cosmos DB SDK Support SLA and gets only best-effort support. The doc comments for these APIs as well as documentation on the feature flag will indicate the same (that replacing the async runtime or HTTP transport makes the application ineligible for the standard support SLA).

As part of this, we can use the `AsyncRuntime` abstraction provided by `azure_core`, but we will likely need to make an addition or two to support things like `timeout` (a runtime-optimized way to apply a timeout to a future) and interval timers. @heaths and I chatted about this and it should be possible to make this addition in an `azure_core` minor version (in my prototyping, I think it can be entirely done via "provided" trait functions so we don't even break existing `impl`s)

Start with CosmosRuntimeBuilder and the AsyncRuntime abstraction provided by azure_core; investigate the required timeout and interval-timer support. Done means the compile-time feature flag enables custom async runtime and HTTP transport APIs, with diagnostic and user-agent markers plus documentation describing the support limitations.

Written by the indexing model from the issue text.