Description

Users that try to use the NuGet package for containers with an SDK that already ships Containers support hit two main blockers that are difficult to work around for users that are not extremely skilled in MSBuild. We should enable users on 8.0 SDKs to use updated 8.0 packages for containerization to satisfy cases where users cannot update SDKs to the latest features.

This PR fixes two things:

1. When the user references the Microsoft.NET.Build.Containers package and sets _ContainersTargetsDir (or it is set inside the package), a warning appears when running dotnet publish -t:PublishContainer that says:

warning MSB4011: "{path}\.nuget\packages\microsoft.net.build.containers\8.0.403\build\Microsoft.NET.Build.Containers.targets" 
cannot be imported again. It was already imported at 
"{path to the project that we try to publish}.csproj.nuget.g.targets (4,5)". This is most likely a build authoring error. 
This subsequent import will be ignored.

2. Silencing the warning

The Microsoft.NET.Build.Containers NuGet package is explicitly referenced but the current SDK can natively publish the project as a container. Consider removing the package reference to Microsoft.NET.Build.Containers because it is no longer needed.

Solution:

1. Importing .targets from internal build only when _ContainersTargetsDir was not set.
2. Adding code to the warning (Chet's commit + test fix)

Customer Impact

Without this, users cannot easily switch to using the Containers package - they get impossible to suppress warnings (which are errors if WarningsAsErrors is enabled) and some of the SDK logic will be pinned in a way that the Containers package cannot overwrite due to MSBuild semantics, so the experience of the user will be mixed.

Regression

Yes, we regressed the 'pluggability' aspect of the user experience in 8.0.200.

Risk

Low - we have excellent test coverage here and have added to it to check the semantics here.