Experiment with compiler support for nint and nuint **NOMERGE**

[GrabYourPitchforks]

We now have a compiler toolchain that supports nint and nuint natively.

The remaining nint / nuint usages in Span<T> and ReadOnlySpan<T> are using the compiler shortcuts for IntPtr and UIntPtr. I created some experimental overloads of APIs in Buffer and Unsafe to act as the targets.

This is not intended to represent production code and will not be committed.
It is meant to exercise CI code paths to see if anything falls over unexpectedly on other architectures.

[ghost]

Tagging subscribers to this area: @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[jkotas]

Did you run into any gotchas with deleting aliases for nuint/uint from everywhere and then just fix the compile errors? I would expect it to be pretty straightforward.

[tannergooding]

Just wondering why this isn't testing things by just removing these aliases? I'd expect us to be able to just remove all of the usings and have things "just work"
If they don't, its likely a compiler bug we should flag @cston on and otherwise, we should be generally good to check things in.
The compiler just uses the built-in IL operators after all and we were already using aliases of the right size....

[jkotas]

I gave it a shot: #36159 . Some places needed an extra unsafe or cast, but it was pretty straightforward otherwise.

[GrabYourPitchforks]

I didn't remove the aliases straight-up because I anticipated there might be problems at [Intrinsic] methods since those might require VM changes as well. Wanted to minimize the number of potential errors for the first attempt.

[jkotas]

Intrinsic

There should not be any (for CoreCLR at least). https://github.com/dotnet/runtime/blob/master/src/coreclr/src/vm/mscorlib.h does not have any 64-bit ifdefs.