Implement compiler flag /warnversion

[gafter]

From #45701

Implement a /warnversion:version command-line switch

1. The version is going to start at 5 and increase monotonically with new compiler releases. It is a decimal value.
   Open Question: do we bump the number for .NET releases or language releases? Today they will be the same but what if that changes?
2. For each warning, the compiler knows which version the warning was introduced in.
3. For any warning that the compiler wishes to emit, it first checks it against /warnversion. If the warning is more recent then it isn't emitted, and can't be controlled by /warnaserror, and #pragma warning restore cannot enable it. For all other subsystems in the compiler, it's as if this warning doesn't exist. If you /warnaserror:WRNID one of these warnings, it silently has no effect.
4. If /warnversion specifies a version more recent than the current compiler, then the compiler silently uses the most recent version it can. If no /warnversion is specified then none of the warning-wave warnings will be produced.

[CyrusNajmabadi]

The version is going to start at 5 and increase monotonically with new compiler releases

I personally don't like that. It makes it feel like i should be ablet o map that value to some value from elsewhere in the ecosystem (i.e. .net version, etc.). I don't see how they're tied together so i would prefer to explicitly not make them seem similar.

It is a decimal value.

I don't like that either. what is a fractional warning wave? i.e. i would not expect to enable warning wave 2 and 2.1 and 2.2. I would prefer it was just integral, and we had a clear doc saying: this warning wave integral value added exactly tehse warnings.

[gafter]

The warning wave number aligns with the version of the dotnet platform in which the warning was introduced.

It is a decimal value because we don't know if dotnet versions will be integral in the future (e.g. dotnet 3.1), or if there will be a release of a component containing the compiler between dotnet versions.