Improve APIs for Intel string handling intrinsics

[CarolEidt]

See dotnet/coreclr#17637 for some discussion and context.
The fundamental issues revolve around how much of the behavior should be controlled by enums passed into the intrinsic method, versus separating the different behaviors into differently-named intrinsics.

The current API includes both StringComparisonMode (https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Intrinsics/ref/System.Runtime.Intrinsics.cs#L864) and ResultsFlag (https://github.com/dotnet/corefx/blob/master/src/System.Runtime.Intrinsics/ref/System.Runtime.Intrinsics.cs#L875).

Some of the open questions are:

• Should the ResultsFlag, which determines the comparison results for which a true result is returned, become part of the method name?
• How should these be named? According to the instruction documentation (e.g. CFlag, as in the current API), or something more descriptive like CompareNonZeroMask?
• Should these be combined into a single enum or remain separate?

[CarolEidt]

@eerhardt @fiigii @tannergooding @4creators - This is intended to be the follow-on discussion from dotnet/coreclr#17637. Please feel free to modify the description or title, and add any context I've missed.

[scalablecory]

I think it'd be simpler to control everything via enum rather than have a large number of methods for random combinations of flags -- otherwise I'll have to keep a translation in my head of what maps to specifically what instruction.

Is this still part of the 3.0 milestone? Very keen to start using these.

[tannergooding]

@CarolEidt, @terrajobst, @eerhardt, @jkotas

I've moved this to future as the APIs we plan to expose here still need more thought/design/etc.

I think someone will need to sit down and take a much deeper look at the instructions and how we should expose them, but I don't think I'll have time to do this before 3.0, so I've marked it as up-for-grabs in case someone from the community wants to have a go.