Respect environment variables for disabling Vector support

[jeffhandley]

As was metnioned in #84115 (comment)_, it would be relatively simple to recognize environment variables for disabling vector support--especially to help with testing.

Today, setting DOTNET_EnableAVX2=0 results in Vector256.IsHardwareAccelerated returning false and setting DOTNET_EnableHWIntrinsic=0 will result in Vector64.IsHardwareAccelerated and Vector.IsHardwareAccelerated returning false.

Instead of requiring those two environment variables to be set and used in different test runs, we could respect DOTNET_EnableVector128 and probably several others. This approach would make the test scenarios easier to reason about..

Tagging subscribers to this area: @dotnet/area-system-runtime-intrinsics
See info in area-owners.md if you want to be subscribed.

Issue Details

---

As was metnioned in #84115 (comment)_, it would be relatively simple to recognize environment variables for disabling vector support--especially to help with testing.

Today, setting DOTNET_EnableAVX2=0 results in Vector256.IsHardwareAccelerated returning false and setting DOTNET_EnableHWIntrinsic=0 will result in Vector64.IsHardwareAccelerated and Vector.IsHardwareAccelerated returning false.

Instead of requiring those two environment variables to be set and used in different test runs, we could respect DOTNET_EnableVector128 and probably several others. This approach would make the test scenarios easier to reason about..

Author:	jeffhandley
Assignees:	-
Labels:	area-System.Runtime.Intrinsics, untriaged
Milestone:	-

[tannergooding]

There is a better way to control this via the DOTNET_MaxVectorTBitWidth property that impacts the size of Vector<T>.

There also exists an undocumented DOTNET_PreferredVectorBitWidth that impacts whether Vector256/512.IsHardwareAccelerated report true.

Vector128 and Vector<T> themselves are "core" types for many platforms and DOTNET_EnableHWIntrinsic is the only way to disable them by design.