Intel Hardware Intrinsics test framework design deficiences

A while ago we have had a long discussion about the scope of testing which should be done during Intel Hardware Intrinsics development (for details see https://github.com/dotnet/coreclr/pull/15771).

There were two proposals put forward:

1. Test as little as possible concentrating on a check if expected assembly instruction is emitted;
2. Test for wider range of values including known problematic ones

Currently we use approach from point 1 which IMO opinion is deficient since it led to several missed implementation bugs i.e.:

https://github.com/dotnet/coreclr/issues/17957 https://github.com/dotnet/coreclr/issues/18039 https://github.com/dotnet/coreclr/issues/18041 https://github.com/dotnet/coreclr/issues/18043

It seems that using small set of problematic values for each numeric type would solve that problem without need for creating complex test scenarios i.e.:

1. for integral types: min, max, -1, 0, 1
2. for unsigned integral types: min, max, 1
3. for floating types: +/- infinity, +/- max/min, +/- 0, subnormal

@AndyAyersMS @CarolEidt @fiigii @sdmaclea @tannergooding

category:testing theme:hardware-intrinsics skill-level:intermediate cost:small