Add empty X64/Arm64 nested classes to some System.Runtime.Intrinsics

[EgorBo]

Rationale

Imagine you have an arm64 CPU with ArmBase and ArmBase.Arm64 support (both are always enabled for any arm64 CPU), but without Aes, Sha1 and Sha256 features, let's run the following snippet:

Console.WriteLine(ArmBase.IsSupported);       // true
Console.WriteLine(ArmBase.Arm64.IsSupported); // true

Console.WriteLine(Aes.IsSupported);           // false
Console.WriteLine(Aes.Arm64.IsSupported);     // true (??)

Console.WriteLine(Sha1.IsSupported);          // false
Console.WriteLine(Sha1.Arm64.IsSupported);    // true (??)

Console.WriteLine(Sha256.IsSupported);        // false
Console.WriteLine(Sha256.Arm64.IsSupported);  // true (??)

The problem here is the fact that Aes, Sha1 and Sha256 inherit from ArmBase but don't define their own Arm64 nested classes, see sharplab.io for more details (it explains why it can't be fixed in the jit).

Proposed API

    [Intrinsic]
    [CLSCompliant(false)]
    public abstract class Sha1 : ArmBase
    {
        internal Sha1() { }

        public static new bool IsSupported { get => IsSupported; }
        
+       public abstract class Arm64 : ArmBase.Arm64;
+       {
+           public static new bool IsSupported => Sha1.IsSupported; // && IntPtr.Size == 8 ?
+       }

(same for Sha256 and Aes)
UPD same for Aes, Avx, Avx2, Fma, Pclmulqdq, Sse3, Ssse3

/cc @tannergooding @echesakovMSFT

Tagging @tannergooding as an area owner

[EgorBo]

Ah, looks like the same problem exists for x64 as well, e.g.:

Console.WriteLine(Avx2.X64.IsSupported);

Prints true on a CPU without AVX2. (because it actually uses Sse42.X64.IsSupported for that)

So we need to do the same for: Aes, Avx, Avx2, Fma, Pclmulqdq, Sse3, Ssse3

[tannergooding]

For x64 this is a possible breaking change if the user recompiles. I still think it provides a better experience, but it is something that needs to be considered.