Multiple dataprotection providers for migration/fallback

### Is your feature request related to a problem? Please describe.
I'm not sure if this is possible at all since the documentation feels rather scarce when it comes to changes to the data protection stores, but we have 2 different migration issues here with changing Data Protection providers:

1. We want to migrate our existing DataProtection keys from one data store to another, relying on the implementation itself to do the work of creating and storing the missing keys rather than us having to work out exactly how the format is different between providers.
2. We've realised after-the-fact that we should have had set the application name for the DataProtection config since we now want to share the existing keys with multiple applications. Adding a name now seems to log out all users which is really not a viable option on a consumer website (last time it happened when we migrated from ASP.NET to Core, we were getting emails about a "bug" and forgotten password issues for months).

### Describe the solution you'd like
If any of the above is already possible, it'd be ideal to include it in the documentation.

If it's not already possible, ideally we'd like to see the following features:
1. The ability to add multiple DataProtection key stores, with the expectation that the key stores have their keys reconciled (maybe have multiple `ReconciliationStrategies`, such as merge and override?) and maintained at a synchronised state.
2. The ability to either add a new ApplicationName for data protection with the expectation that keys referring to the old name are migrated, or, similar to above, the ability to add multiple application names and have identical keys maintained for both names.
3. Pertaining to #1, if there are already multiple key stores defined, the ability to use a synced key store for fallback might be a welcome addition in certain scenarios such as in the case of geo-replicated Kubernetes clusters, but this is really more of an optional idea if there are already multiple key stores anyway.

These could be either implemented via a new `IKeyManager` or `IXmlRepository` store, or implemented directly in the core of the data protection system. I can see pros on both sides of this issue.