Remove the netstandard support for dotnet

[joelverhagen]

This addresses two different updates to the netstandard story:

1. netstandard should not support dotnet. See Break compatibility between netstandard and dotnet Home#1963.
2. Add more tests around netstandardapp.

@emgarten @anurse @ericstj @davidfowl

[analogrelay]

Looks good to me. One thing to consider (for the near future) is how netstandardapp1.6+ will work. Will we have to keep updating the mapping or is it designed to automatically track netstandard versions? I think the latter is ideal (if it doesn't already do that).

[joelverhagen]

@emgarten, correct me if I am wrong here, but the current code has two possibilities for this.

1. Add a rule that netstandard is a "subset framework" of netstandardapp. This means all version numbers map automatically, akin to your latter recommendation. However, this means netstandardapp1.4 would support netstandard1.4, netstandardapp99.9 would support netstandard99.9, etc. -- which is a bit different than what @ericstj requested (netstandard1.5 should be the lowest mapped).
2. Add explicit mappings between each pair. This is the approach I took (the only one right now is netstandardapp1.5 supports netstandard1.5. When 1.6 comes out, we will need to make a code change.

The third possible approach is of course implement a new kind of relationship that is something like subset mentioned above but only for TFMs with versions greater than or equal to X.Y (1.5 in this case). This would be a significantly larger change than the approach I have taken.

[analogrelay]

I think @ericstj was OK with having the underlying NuGet code allow all the mappings and have the 1.5 minimum be something enforced via templates, docs and other warnings (perhaps editor squiggles and stuff). I'd definitely prefer option 1 to option 2 since it means new TFMs immediately start working without complex code around setting a minimum bar.

But of course, he can chime in to clarify :)

[emgarten]

I agree with @anurse keeping the subset rule would be best here. Forward compatibility here for nuget frameworks is typically the most important thing.

Validating and restricting poorly authored packages that use incorrect frameworks is ideally done by the pack command and by nuget.org when a new package is uploaded.

[ericstj]

That's OK with me, but I still have hope that all of this code will go away and be replaced with a data file.
The main reason I called out that NETStandardApp1.5 was the first supported one is that it doesn't make sense for us to ship NETStandardApp1.0-1.4 once we already have 1.5.

[analogrelay]

Agreed on the data file. I don't think anyone likes having to maintain this code ;P

[emgarten]

[analogrelay]

FYI now that this is in, we're going to need NuGet/Home#1962 fairly soon.