Revisit Key behavior

[HaoK]

@divega wrote:

cc @kirthik, who made the change and touched this line previously. I think this is kind of intentional, but also something we could discuss:

The Key property was added to the IConfigurationSection interface with the intention of providing metadata about the configuration node corresponding to the instance. From that perspective the new behavior provides de most information. With the previous behavior it would have been cumbersome to obtain this information.
Personally I wasn't even aware that there was a Key property hanging there previously. Presumably it was not in the interface but in the class? From that perspective this is a subtle breaking change that even @kirthik missed she had to react to when she previously adjusted this code. It has now became cumbersome to obtain jus the last key segment if that is what you need.
In theory we could expose both, e.g. Key and FullKey. Not sure is a good idea as it makes the API more complicated for everyone. We should really look and the scenarios...
Regardless, it seems that at the minimum we should go back at the places where ConfigurationSection.Key was being used across the stack and make sure we don't leave them broken.

@HaoK wrote:
Could also consder just splitting it into two properties like:
ParentPath and Key, so basically you can just concat the two to get the current full path behavior, and Key is untouched and remains the last segment.

[divega]

Putting in the beta 7 milestone for now because it would make sense to avoid the braking change going out in beta 7 if we can.

[divega]

Decisions:

1. We will go back to the previous behavior of Key: configuration.GetSection("A:B").Key == "B"
2. We will add a FullKey property: configuration.GetSection("A:B").FullKey == "A:B"
3. We need to make sure that on the API calls on a given node we honor the prefix that applies to it: configuration.GetSection("A").GetSection("B").FullKey == "A:B"