Cosmos -> CosmosStore and related renames

[bartelink]

Re #197, renaming to align with principles in the Azure Core SDK conventions: https://azure.github.io/azure-sdk/dotnet_introduction.html

• introduce prefixing to reduce clashes with equivalents from other namespaces (i.e. Equinox.EventStore.Resolver vs Equinox.Cosmos.Resolver). (Grpc variant of EventStore wrapper will follow this convention too)
• rename namespace Equinox.Cosmos.* to Equinox.CosmosStore (this allows V3 to sit alongside V2 and/or would enable us to provide a fully side-by-sideable V3 variant of Equinox.Cosmos if ever required)
• rename Equinox.Cosmos.Store.* to Equinox.CosmosStore.Core.* e.g. Equinox.CosmosStore.Core.ContainerClient. (should not affect any normal consumer scenarios)

Key name changes:

• Equinox.Cosmos -> Equinox.CosmosStore
• CosmosStoreClient -> CosmosStoreConnection (which was it's original name, and is back to being consistent with the EventStore based store adapters)
• Context -> CosmosStoreContext
• Resolver -> CosmosStoreCategory

For now, this scheme suggests there should not be a need to provide obsoletion placeholder types to ease migration. (not certain it makes sense at this point)

[bartelink]

Also think CosmosStoreClientFactory yielding a CosmosClient which you then supply to a CosmosStoreClient is way too confusing so something needs to happen. Also CosmosStoreContext and CosmosStoreCategory after that is not making it easier

🤔 maybe the answer is to merge some stuff into a CosmosStoreOptions and perhaps consolidate one or more of the above.

@ylibrach After lots of thought and experimentation, it turns out that the original name (*Connection) fits best as

• it's distinct from the CosmosClient (avoids having to be overly specific in naming in wireup code - client can unambiguously mean CosmosClient)
• It makes the presence of the type CosmosStoreClientFactory in the normal wireup code less confusing (I still can't say I love the name, but it's technically correct and there are definitely worse names)