Implement IL2C specialized tfm

[kekyo]

I was thinking that an IL2C-specific tfm would have to be defined at some point, but the sooner the better.
With #79, now that we have a fully automatic build, I think we will have more opportunities to try IL2C closer to home. In that case, if we had our own tfm, we could easily detect the "is this supported?" that has been raised several issues in the past.

NET developers routinely switch tfm to detect if an API is supported or not (maybe it's just me). For example :

var address = await Dns.GetHostAddressesAsync("www.google.com", token);

Overloading is only available in .NET 6 and above. To discover this early, use :

<PropertyGroup>
  <TargetFrameworks>net48;net6.0</TargetFrameworks>

by using multiple targets, the developer can detect this overload as an unresolvable problem for net48 at compile time.

Digging deeper, net48 and net6.0 will cause implicit references to libraries, especially mscorlib and System.Private.CoreLib (or System.Runtime) assemblies, to switch between defined and undefined symbols, which will be reflected in successful compilation. Also, in the case of external libraries, NuGet interprets these tfm's to include the appropriate package's libraries in the project's dependent libraries, which switches symbols between defined and undefined in the same way.

As an introduction to IL2C-specific tfm :

• Resolving tfm names like netil2c1.0 (not sure how, hope it is not hard-coded somewhere in NuGet's library or in MSBuild's scripts or tasks...)
• If an IL2C tfm is specified and built, have a stub assembly like il2ccorlib.dll linked in as a standard library. The contents should be empty or always throw an exception.

[kekyo]

The motivation for the stub assembly came from #91 . I was hesitant at first because of the seemingly high cost of maintaining this, but I am inclined to say that it might be better to maintain it now (before we are plagued with a large number of APIs later). As a first version, manual maintenance might be fine (provided it is in a format and method that can be automated later).

[kekyo]

Bit related #52

[kekyo]

I found it from NuGet.Frameworks repo: https://github.com/NuGet/NuGet.Client/blob/f1c5b47018d84ff0bff7aa0fc5fedc7c3db95f34/src/NuGet.Core/NuGet.Frameworks/DefaultFrameworkMappings.cs#L10

It implements IFrameworkMappings to provide a specialized key dictionary of the default set of tfm components. As for the NuGet.Frameworks library, an interface consisting of this interface and IFrameworkNameProvider is available as an extension point.

However, this default key dictionary is still hard-coded, so it appears that new keys cannot be inserted without recompiling the library for calls from existing code in MSBuild 💀