Rename/reorg .Cosmos to .CosmosStore

[bartelink]

As part of the V3 release line, there are significant features being added that collectively make this the right time for some reorganization of the Equinox.Cosmos API structure.

The result is that the default CosmosDB Store package will split into

1. Equinox.Cosmos

• is maintained on the v2 branch
• Uses Microsoft.Azure.Documents (aka V2) CosmosDb client
• will not have breaking changes relative to the Equinox.Cosmos V2 APIs (nuget 2.x -> 3.x upgrades should be trivial)
• will work with Propulsion.Cosmos 2.x (which will continue to use the V2 CFP until the CheckpointAsync API is reinstated

2. Equinox.CosmosStore:

• is maintained on the master branch
• uses Microsoft.Azure.Cosmos (aka V3) SDK but will move to V4 as soon as that's available eta: end '20
• should not have egregious renaming relative to Equinox.Cosmos
• will over time gain all the functions previewed in feat!(CosmosStore): Azure.Cosmos 'V4' support / enable mocking Cosmos APIs #197 (this PR is effectively a cherry pick of same) 🙏 @ylibrach for prompting the reorg

More details / rationale:

• master, and the V3 release line will use the Microsoft.Azure.Cosmos package (depending on when the Cosmos V4 SDK lands (eta end '20), it may use the Azure.Cosmos release)
• naming, particularly when interfacing with CosmosDB, will follow the .NET Azure SDK Design Guidelines, whichin particular calls out short, ambiguous, names as something to avoid
• The Fallback feature in Primary-Secondary Fallback WIP on v4 #238 as part of the tiered storage in Add tiered stream management docs #226 requires multiple clients to be supplied when establishing a context
• The long-planned optimization to store events in the tip Cosmos: Harden and merge tip-isa-Batch branch #109 (and ancillary features such as external snapshots Cosmos: Provide ability to separate storage of snapshots #61) trigger a need to provide a generalized loading pipeline