Optimize System.SpanHelpers using arm64 intrinsics

[BruceForstall]

This item tracks the conversion of the System.SpanHelpers class to use arm64 intrinsics.

Related: #33308

[GrabYourPitchforks]

A nit about these functions that might not be immediately obvious:

SpanHelpers.IndexOf(ref byte, ...) and SpanHelpers.IndexOf(ref char, ...) are used as the workhorses for the strlen and wcslen implementations. The caller lies about the length parameter and assumes that if the null character first occurs at page n, the IndexOf method will never attempt to dereference page n + 1. We have some limited unit tests for this scenario as shown below, but I wanted to make whoever attempts to intrinsicify this method aware of this behavior.

runtime/src/libraries/System.Runtime/tests/System/StringTests.cs

Lines 48 to 68 in c0ddd1c

	[Fact]
	public static unsafe void Ctor_CharPtr_DoesNotAccessInvalidPage()
	{
	// Allocates a buffer of all 'x' followed by a null terminator,
	// then attempts to create a string instance from this at various offsets.
	const int MaxCharCount = 128;
	using BoundedMemory<char> boundedMemory = BoundedMemory.Allocate<char>(MaxCharCount);
	boundedMemory.Span.Fill('x');
	boundedMemory.Span[MaxCharCount - 1] = '\0';
	boundedMemory.MakeReadonly();
	using MemoryHandle memoryHandle = boundedMemory.Memory.Pin();
	for (int i = 0; i < MaxCharCount; i++)
	{
	string expectedString = new string('x', MaxCharCount - i - 1);
	string actualString = new string((char*)memoryHandle.Pointer + i);
	Assert.Equal(expectedString, actualString);
	}
	}

[kunalspathak]

IndexOf(char), IndexOf(byte) , IndexOfAny(byte) are now optimized with ARM64 intrinsics. We didn't optimize SequenceCompareTo(byte) and SequenceEqual(byte) because the existing SIMD vector implementation is fast enough and comparable with ARM64 intrinsics.