[5.0] Versioning in the 5.0 universe

[wtgodbe]

With CoreFx moving to 5.0 branding, we have an opportunity to unify our various versioning schemes. Meaning that ProductVersion, FileVersion, AssemblyVersion, and PackageVersions can likely all be bumped to something in the 5 band. We should come up with a plan for what this will look like so we can get into a good state before we start shipping packages to customers.

TODO:

• [x] - Update AssemblyVersions for all assemblies
• [x] - Update packageIndex.json with new AssemblyVersions
• [x] - Remove packages that we wish to dead-end (e.g. System.Reflection.Emit.*, Microsoft.Bcl.*)
• [x] - Update ProductVersion - done by https://github.com/dotnet/corefx/pull/39503
• [x] - Update PackageVersions - done by https://github.com/dotnet/corefx/pull/39503
• [x] - Update FileVersions - done by https://github.com/dotnet/corefx/pull/39503
• [ ] - Write a versioning doc for 5.0
• [x] - Update TFM to something like netcoreapp5.0
• [x] - Undo disabling PackageIndex check (https://github.com/dotnet/corefx/pull/39503/commits/7611a2e965f7389a0ad9332ffa12743cd18ebe6c)

CC @ericstj @leculver @safern @joperezr @danmosemsft

[wtgodbe]

Once we update AssemblyVersions, we'll need to add mappings into packageIndex.json for them.

[wtgodbe]

CC @Anipik

[leculver]

~ClrMD versions (and ships) completely independently from .Net Core and its versioning scheme. Is there any expected action for me and the library here? I would like to remain on "ClrMD 2.0" as it makes the most sense for the library.~

Edit: Just realized this is not in relation to ClrMD, I wear too many hats these days...

[leculver]

What will the first version range for .Net 5 look like? I just wanted to confirm it doesn't overlap with Silverlight Watson crashes.