Unable to tell why a certain value was selected when multiple filters exist

When working with `IConfiguration` in general, there is a `GetDebugView` in `IConfigurationRoot` that provides one with the keys and their sources. This is very helpful to understand what is happening when various providers are involved in generating the final set of settings.

However, when using `AzureAppConfigurationProvider` in more advanced scenarios, this becomes harder to reason about. For example, take this possible integration:
```csharp
config.AddAzureAppConfiguration(
c => c
.Connect(
endpoint: config.GetValue("Azure:AppConfiguration:Endpoint"),
credential: new DefaultAzureCredential())
.Select(KeyFilter.Any, LabelFilter.Null)
.Select(KeyFilter.Any, "Application: MyApp")
.Select(KeyFilter.Any, $"Machine: {Environment.MachineName}"))
```
Given any key that was fetched from Azure AppConfiguration, there is no way to know _why_ that key was fetched. Was it because it had no labels? If I was expecting value `x` but got value `y`, how can I tell which of the labels "won" between the application and the machine? There is no information regarding which labels matched a given key when inspecting the loaded configuration.

This becomes a bigger problem once we abstract this further. Currently, we have a UI in our system where people can navigate and change settings on the fly. We have this mapped to our own internal system which supports either global values, or per-machine values. To support that scenario in Azure AppConfiguration is easy enough: we just add the `Machine: ...` label and fetch it using the current machine name like the above with priority over the `no label` entries, and we get the exact same behavior. But when presenting those settings, we don't have a way to tell where they came from: were they defined globally, or where they defined on the specific machine?

If we had a way to know which label that value came from, we would be able to categorize the key properly.

I'm not even sure a workaround to this is possible right now. Even if we split all of our `Select` calls into completely separate `AddAzureAppConfiguration` calls (which would probably be vastly less efficient) I don't see how we would differentiate the various `AzureAppConfigurationProvider` instances either.