Prepare for a 'netcoreapp3.1' TFM

[dougbu]

To minimize merge conflicts from 'release/3.1' -> 'master':

1. Remove most .NET Core TFMs from our project files and replace “netcoreapp3.0” with a property defined in the root-level Directory.Build.props file. This is a purely mechanical change (especially in VS Code) but will touch hundreds of files. (There are 631 .csproj files in the AspNetCore repo.)
   • property should be named $(DefaultNetCoreTargetFramework) to match 'master'
2. Change our ref/ assembly generation to name the C# files *.netcoreapp.cs instead of *.netcoreapp3.0.cs. The work is mechanical but involves a couple of quick steps after updating a few lines in the MSBuild code we use to generate the ref assemblies. (There are 110 *.netcoreapp3.0.cs files in the AspNetCore repo. The .csproj files in the same directories will also be updated.)
   • update eng\scripts\GenerateReferenceAssemblies.ps1 to match 'master'
   • git rm **/*.netcoreapp3.0.cs
   • execute eng\scripts\GenerateReferenceAssemblies.ps1
3. Change our #if NETCOREAPP3_0 checks to be #if NETCOREAPP. (There are 12 *.cs files in the AspNetCore repo using the 3.0 symbol.)
4. Change version prefix from alpha to preview.

• aspnet/AspNetCore (mostly done but in 'master' and [master] Update dependencies from 3 repositories #13548 shows even that needs more work; must be done in 'release/3.1' as well)
• aspnet/AspNetCore-Tooling
• aspnet/EntityFramework6 ([release/6.4] Update dependencies from dotnet/core-setup ef6#1223 has this but needs more work)
• aspnet/EntityFrameworkCore ([release/3.1] Update dependencies from aspnet/Extensions efcore#17658 needs this)
• aspnet/Extensions
• aspnet/Blazor for the branding change only: dotnet/blazor@1eb0ac0

Details

These changes have the added benefit of easing TFM changes e.g. adjusting to the new netcoreapp3.1 TFM but that is not the primary goal. W.r.t. merge conflicts:

1. Avoids merge conflicts as we touch nearby lines in the project files.
2. Avoids merge conflicts as ref assemblies need to be updated. Without the proposed change, the generated files won’t exist in the target repo and the files that do exist will need to be manually updated. This may be change with the largest impact.
3. Avoids merge conflicts as we touch nearby lines in the C# files.

[JunTaoLuo]

FYI, we're running into NuGet/Home#8467 which I'm working around by specifying NoWarn. These workarounds should be removed once we have an updated SDK with the NuGet fix.

[dougbu]

@JunTaoLuo can't those issues be worked around by adding _._ files to the .nupkg or fixing the project file?

When we saw this error before, it indicated a real problem in the Components project (which we haven't fixed): The source-built .nupkg doesn't contain the expected files because single-TFM projects don't lay out the obj/ folder with a TFM in the directories (IIRC).

[JunTaoLuo]

We can workaround NU5128 with that. Don't think that's going to help with the NU5131 issues though.

[dougbu]

Ah, right. I see others are disabling NU5131 warnings.