.Net: [MEVD] Cosmos NoSQL provider work on keys, partition keys and point reads

[roji]

This is a sizable cleanup/redo of large chunks of the Cosmos NoSQL provider; I've broken it down to three commits for easier reviewing.

• Cosmos NoSQL collections can now have either string/Guid as their key, or CosmosNoSqlKey. In the former case, this configures the partition key to be the same as the string/Guid document key - this is a sensible default that's common (and encouraged) in Cosmos. All other scenarios require CosmosNoSqlKey:
  • A single partition key that isn't the document ID
  • A hierarchical partition key (more than one property)
  • No partition key (legacy/discouraged)
• Note that CosmosNoSqlKey is only passed to GetAsync and DeleteAsync; on the user's .NET record type, the properties are there as usual (e.g. a string document Id property, an int partition key property). This introduces a discrepancy for the first time between the collection's TKey (CosmosNoSqlKey) and its actual key property on the .NET type (a string); this made some things trickier, but is the correct way to do things for composite key cases (we'd do the same if we implement composite keys for relational providers).
• Added support for Cosmos hierarchical partition keys (2-3 properties instead of just one).
• GetAsync no longer does a SQL query with a WHERE clause, but rather an efficient point read via ReadItem. The multiple-key overload does ReadManyItemsAsync, which again is far more efficient.
• UpdateAsync and DeleteAsync now correctly supply the partition key in the call's request options, again making it much more efficient.
• Various other cleanup and fixes all around.