Corvus.Identity.MicrosoftRest needs to cache tokens

The adapters in `Corvus.Identity.MicrosoftRest` enable `Microsoft.Rest`-based clients (e.g., older Azure client SDKs, or clients generated with Autorest) to use `Azure.Core`-style credentials (normally supplied by `Azure.Identity`). However, these are currently not very efficient—they end up fetching new tokens too often. In particular, when using Azure Managed Identities, we hit the relevant token endpoint far too often.

This is because there are mismatched expectations. In the old `Microsoft.Rest` world, client code assumed that the credential provider did token caching, but now the onus is on the client.

This may seem like a peculiar choice—there's only one Managed Identity implementation of `TokenCredential`, and any number of client libraries that might want to use it, so you'd think the onus would be on the credential provider. However, `Azure.Core` introduced a design change that means that in theory, neither the client SDK nor the credential provider are responsible for this: instead, token caching now happens in the HTTP pipeline.

Most of the time that's great: there's now a single token cache that works for any (client SDK, credential provider) combination. This means that neither credential providers nor client code is on the hook.

The one snag is that if you're not using the `Azure.Core` HTTP pipeline you're now back on the hook for providing caching.

And the nature of `Corvus.Identity.MicrosoftRest` is that it's used by code that isn't using `Azure.Core`.

Sadly, the caching component in `Azure.Core` is a private nested class of one of the HTTP pipeline classes. However, I think we can still take advantage of it: if we derive from that pipeline element, we can get access to methods that will invoke the cache code. The one irritation is that it will require us to build an `HttpMessage` on which it will set the header, but there doesn't seem to be a practical way for us to pass it the actual `HttpMessage` that will be used by the `Microsoft.Rest`-based client. So we'll just have to build an `HttpMessage` whose only purpose is to be the recipient of the relevant header, which we will then copy back out.