Specification for Azure service granularity

This is a follow-up of #646 to deal with Azure service specific parts:
- for some other hosted NoSQL services like `dynamodb`, we use the cloud region name in place of the `db.instance` field.
- for Azure services, the region name is usually not directly accessible, which means having access to this value might be hard or impossible when doing instrumentation.
- this might not be specific to CosmosDB, thus we need to know if we can have a consistent strategy for all the Azure services (for example for Azure messaging services we always have a queue or topic name to use first, but the account name could be used as a common fallback when the queue or topic name is not available.

It seems however that the Account Name is usually always available as it's usually part of the remote service endpoint/URL.

Also, this common strategy is very likely to be used for `storage` spans: `azureblob`, `azurefile` and `azuretable`.