Add obsolete warning for DotNetCliToolReference packages that are now built-in commands

[natemcmaster]

A few ASP.NET Core packages that used to be installed via DotNetCliToolReference will be built-in commands for the CLI. When invoking "dotnet watch" now, it will use the built-in version, not the one delivered via DotNetCliToolReference, so DotNetCliToolReference should be removed.
cref aspnet/Announcements#290.

Since we don't have a proper way to issue obsolete messages about packages (NuGet/Home#2867), can we add a target that runs before Restore that issues an obsolete warning for the following packages

<ItemGroup>
   <DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="(all versions)" />
   <DotNetCliToolReference Include="Microsoft.Extensions.SecretManager.Tools" Version="(all versions)" />
   <DotNetCliToolReference Include="Microsoft.Extensions.Caching.SqlConfig.Tools" Version="(all versions)" />
</ItemGroup>

Proposed text:

warning SDK0000: the DotNetCliToolReference to Microsoft.DotNet.Watcher.Tools is obsolete. This tool is now bundled in the CLI. The DotNetCliToolReference can be removed.

[livarcocc]

@dsplaisted @nguerrera do we have a good place to do that in the SDK? Or is this something that we should probably ask NuGet to do (that's my initial preference).

[dsplaisted]

We could do this in the SDK if we had to. There are a few other options that don't involve new features.

ASP.NET could publish updates to the packages that would have a .targets file in them that generated a warning. This would work without any new NuGet features, but would only warn if these packages were updated to the latest versions.

Another option would be to have the new watch tool scan your project for the outdated tool references and generate a warning if they are found.

[natemcmaster]

We considered some of these. Unfortunately...

ASP.NET could publish updates to the packages that would have a .targets file in them that generated a warning.

DotNetCliToolReference doesn't import targets, only PackageReference.

Another option would be to have the new watch tool scan your project for the outdated tool references and generate a warning if they are found.

This might work and is the alternative we've considered, but we wanted to raise the visibility of the warning to restore if possible. Also, implementing this kind of scanning can be a pain due to dotnet/msbuild#1097

[natemcmaster]

FWIW - I'm inclined to push harder for NuGet/Home#2867 too, but I have no idea how much NuGet has on their plate right now.

[natemcmaster]

@livarcocc would you accept a PR to add this the SDK? I don't think we're going to get NuGet changes for this.

cc @muratg @DamianEdwards

[livarcocc]

It would depend on the nature of the PR 😄

[natemcmaster]

Done in #2064