Remove Configuration Group and OS Group from the Our config system

[Anipik]

The 3 major tasks here will to be able to

• Cross-Compile.
• able to pass to project to project dependencies.
• should be able to find the best configurations from the project while building from the root.

The starting point here will be to make this work for a smaller repo.

cc @ericstj @danmosemsft @safern @ViktorHofer

[stephentoub]

Can you elaborate on what it means to remove these? I use these to cross-compile and validate debug vs release all the time. If we're removing these properties, there needs to be a similarly easy mechanism in place.

[ericstj]

The goal is to stop overloading Configuration with our targeting information and instead use TargetFrameworks since this is supported by the SDK.

So mapping today's concepts to desired concepts:
ConfigurationGroup -> Configuration
TargetGroup-OSGroup -> TargetFramework-OSGroup
BuildConfigurations -> TargetFrameworks (where individual values are encoded as TargetFramework-OSGroup)
PackageConfigurations -> (TBD) some flag set for specific configurations rather than a static list, EG: IncludeInPackage = True|False, I believe the SDK has a property we can use here.

The benefit of doing this is it gets rid of Configurations.props and the lists of configurations in the project files, it also eliminates the need for generating SLN files. It should also make cross-targeting work more naturally in VS. It eliminates our cazy graph of generated props files.

[stephentoub]

Ok, cool. Sounds like all the capabilities will still be there, just better/more consistent, in which case... 👍