Determine caching mechanism for key vault secrets

Currently, if client code repeatedly asks for storage contexts (instead of caching them) and if the credentials required to populate those contexts live in key vault we can end up fetching the secrets again and again.

We need to determine how we are going to cache them. This isn't entirely straightforward because caching information stored in key vault secrets introduces potential security risks. So we need to define clearly what our expectations are around the nature of the secrets (e.g., the requirements for key rotation to minimize exposure with 'dumpster diving' type attacks).

We also need to determine whether this code belongs in here, in `Corvus.Identity.Azure` (which is where some of the code that needs to use credentials from key vault lives, so it also needs a solution to this problem) or some other library.

Related to this, `SqlConnectionFactory` currently duplicates some code from `CachingStorageContextFactory` because it has need of caching, but doesn't want to reuse contexts in the way that other storage providers do (because a `SqlConnection` is used by one thread at a time).