Use RID less targets to obtain compile assets

[natidea]

NuGet/Home#4207 reports that NuGet is incorrectly including runtime assemblies in the "compile" assets for RID-specific targets. This is compounded by the fact that this SDK populates References using compile assets from RID-specific targets, but these compile assets should be independent of RID, and come from the RID-less targets.

This change derives ResolvedCompileFileDefinitions and ResolvedFrameworkAssemblies from file dependencies with parent target equal to NuGetTargetMoniker (i.e. excluding the RID if one exists)

A fix for the NuGet issue is available (NuGet/NuGet.Client#1103) but is not currently targeting RTW because of risk. My fix may also carry some risk for any scenarios where builds were previously working by accident because we were pulling in runtime assets. But making this available for consideration in case we decide to take it.

Fixes #592

/cc @emgarten @dsplaisted @srivatsn @nguerrera @ericstj

[emgarten]

LGTM

[natidea]

/cc @MattGertz we would like to bar check this at shiproom.

Customer scenario

The SDK pulls in "compile" assets from RID-specific targets, but these compile assets should be independent of RID, and come from the RID-less targets. Normally the "compile" assets should be the same across all targets, but a bug in NuGet (NuGet/Home#4207) results in NuGet incorrectly including runtime assemblies in the "compile" assets for RID-specific targets.

The customer impact is that if Runtime assemblies in a package are inappropriate for inclusion in compiler references, they could get a compile break. So far the only customer to encounter this is CoreFx and they have a workaround (dotnet/core-setup#1029 and dotnet/corefx#15933)

Relatedly #696 reports that Runtime-specific build fails when a project with a RID has a P2P reference to a portable project with no RID. Some of those errors would be fixed by this change because we would not be using the RID-specific target. However, strictly speaking, the complete fix provided in #828 does NOT require this change since it removes the RuntimeIdentifier for projects where it shouldn't apply anyway.

Bugs this fixes:

#592
Removes some of the errors in #696

Workarounds, if any

CoreFx worked around this by modifying their package (dotnet/core-setup#1029 and dotnet/corefx#15933)

Risk

If a customer was relying on this incorrect behavior (i.e. by taking a compile-time dependency on runtime assemblies) then they would be broken.

Performance impact

None

Is this a regression from a previous update?

No

Root cause analysis:

We missed this nuance when porting this feature from the legacy Microsoft.NuGet.targets

How was the bug found?

Reported by partner team

[nguerrera]

Waiting for test