Handle conflicts between a ref-only Microsoft.AspNetCore.App and individual packages

[natemcmaster]

Problem

Follow-up to #3608. By making Microsoft.AspNetCore.App a ref-only package, we introduce the possibility of conflicts with other packages, like Microsoft.Extensions.Logging. Both packages would contain assemblies with the same name and version. The .NET Core SDK may not automatically be able to resolve these conflicts, so we need to provide additional information to the conflict resolver on how to handle this scenario.

Proposed solution

Re-use the mechanism that Microsoft.NETCore.App introduced in 2.0 when moving from granular System.* packages to a ref-only package.

1. Include a platform manifest (for dotnet publish conflict resolution)
2. Supply PackageConflictOverrides MSBuild metadata for the conflict resolution task

Requirements

1. A project using netcoreapp3.0 and Microsoft.AspNetCore.App should be able to reference the packages and projects which use Microsoft.Extensions.Logging < 3.0.0.
2. A project using netcoreapp3.0 and Microsoft.AspNetCore.App should build without errors when Microsoft.Extensions.Logging 3.0.0 is referenced (even though its inclusion should be unnecessary)
3. When packages formerly referenced from Microsoft.AspNetCore.App < 3.0 end up in a netcoreapp3.0 project, they should not end up in publish output for framework dependent apps.
4. When packages formerly referenced from Microsoft.AspNetCore.App < 3.0 end up in a netcoreapp3.0 project, they should not replace the version in publish output which will come from the runtime-specific version of Microsoft.AspNetCore.App (see Produce platform-specific packages for Microsoft.AspNetCore.App #3607)

[dsplaisted]

This NuGet feature would allow us to pass a list of these packages to NuGet and have them excluded from restore: NuGet/Home#7344

[dsplaisted]

We have proposed a NuGet feature that would address this: NuGet/Home#7344