net5 tfm: "hydrating" empty TargetPlatformVersions

[zkat]

NuGet itself doesn't have the information it needs in order to understand what version net5.0-ios and such might mean, but omitting versions is an important part of this feature.

After discussions with the dotnet and msbuild teams, my understanding is that they will "fill in" the NuGetFramework instances with the actual version using some API call that's yet to be determined (or, preferably, hand us a new one, so we can keep NuGetFramework immutable).

[dsplaisted]

We will be splitting the NuGetFramework into the following MSBuild properties:

• TargetFrameworkIdentifier
• TargetFrameworkVersion
• TargetFrameworkProfile (this is for completeness, we don't expect this to be used normally)
• TargetPlatformIdentifier
• TargetPlatformVersion

If the platform version isn't specified in the NuGetFramework, then the TargetPlatformVersion will initially be unset, and the targets for that platform will set it to a default value.

NuGet should be reading from the 5 component properties in various scenarios, and that's how NuGet should be picking up what the target platform version is.

Here's an issue tracking doing this in the targets for Windows: dotnet/sdk#11233

[nkolev92]

Related to #9443 and probably should be considered under #5154

[nkolev92]

Reading the target frameworks in the inner build will make this possible.

[zkat]

This will be fairly straightforward once #9756 is implemented.

[nkolev92]

#9756 is merged, so this can probably be closed now.

It might be nice to grab the latest SDK and verify the scenario once the NuGet insertion that should be started tomorrow completes.

[zkat]

This is likely already done, and just needs to be tested against dotnet's changes.

tl;dr, we need to check that when we multi-target net5.0 and net5.0-windows, that we have two different frameworks and we don't have a random "windows-7.0".

Closing this in favor of #9873