Cosmos: Allow users to pass in CosmosClientOptions to UseCosmos()

[roji]

Cosmos supports passing configuration to CosmosClient via CosmosClientOptions. EF doesn't currently allow to be passed directly by the user - we instead wrap those options, exposing EF mechanisms for specifying them instead. Unsurprisingly, new options have been introduced on CosmosClientOptions which we haven't kept up with; there's general consensus in the team this isn't a great story, and that some mechanism for passing CosmosClientOptions to UseCosmos() makes sense.

The main reason EF wraps CosmosClientOptions options is that CosmosClientOptions doesn't currently support value equality, and so cannot be compared in EF's internal service provider cache - see #35481 for a more general discussion of that problem (which also affects other providers). One way forward on that is Azure/azure-cosmos-dotnet-v3#4965, which would add value semantics to CosmosClientOptions, and so we could use our normal caching mechanism as usual (but that wouldn't help the general problem in #35481, e.g. for other providers).

Even if that isn't implemented, we could still add an API accepting CosmosClientOptions, and do one of two things:

1. Simply ignore CosmosClientOptions in the options caching. As long as users don't vary the configuration (the vast majority?), everything works fine. If users do vary, later options get ignored and the first CosmosClient gets picked up (bad).
2. Use reference identity for the caching. Everyone using AddDbContext/OnConfiguring will immediately get "too many service providers" if they use AddDbContext/OnConfiguring (since the instance is always different).

Once we introduce such a mechanism, we could also optionally obsolete the current wrapping options, pointing users to the new API instead.

/cc @Pilchie @NinoFloris