Fix bad case-insensitive ASCII equality check

[GrabYourPitchforks]

Fixes #45889. There was an edge case where the characters '`' and '@' would inadvertently compare as equal under OrdinalIgnoreCase. This PR also introduces a unit test to run through all combinations of ASCII chars to look for other edge cases, and it looks like this was the only edge case.

My AMD-based dev box is reporting a tiny perf improvement: maybe 1 cycle or so. I'm not able to measure this with much accuracy, so I'd depend on the perf lab to let us know if something has gone horribly wrong. Since we're reducing the overall code size I wouldn't expect throughput to regress.

This will need to be backported to 5.x and 3.x.

[GrabYourPitchforks]

FYI to reviewers - the diff is a few dozen lines, but that's mostly because I rewrote the comments in the code to clarify exactly what the bit twiddling accomplishes. The fix itself is only a half dozen lines or so, duplicated across 4 methods.

[GrabYourPitchforks]

Latest iteration only changes the unit test. Easiest way to review the single-commit delta is to ignore whitespace changes: 7380c45?diff=unified&w=1

[EgorBo]

@GrabYourPitchforks a general question: have you tried to vectorize Ordinal.EqualsIgnoreCase ? I see it's currently "vectorized" via GP registers or it doesn't make sense?

[EgorBo]

NIT: would be nice to address Ben's feedback dotnet/coreclr#20734 (comment)
(UInt32OrdinalIgnoreCaseAscii -> UInt32OrdinalIgnoreCaseAsciiEqauls) but I guess it's better to keep as is for less painful backport to 3.1 and 5.0.

[GrabYourPitchforks]

@EgorBo We measured it a while back. Vectorization really only provides a benefit when we're talking about long-ish inputs (over a few dozen chars). Since typical inputs to this method are on the order of ~10 chars max, using non-vectorized code incurred less overhead than using vectorized code and had better perf characteristics.

[GrabYourPitchforks]

• @adamsitnik, because you like weird bit twiddling tricks :)

[GrabYourPitchforks]

/backport to release/5.0

[github-actions]

Started backporting to release/5.0: https://github.com/dotnet/runtime/actions/runs/422106031

[github-actions]

@GrabYourPitchforks backporting to release/5.0 failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch

Applying: Fix bad case-insensitive ASCII equality check
error: sha1 information is lacking or useless (src/libraries/System.Runtime/tests/System/StringTests.cs).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 Fix bad case-insensitive ASCII equality check
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

[GrabYourPitchforks]

Ah, yeah, looks like the recent source tree rename may have killed the poor backport bot.

[adamsitnik]

@GrabYourPitchforks I must admit you have a very unusual way of spending your winter holidays. Is Cyberpunk that buggy? ;)

Jokes aside, big thanks for not just fixing the bug but also providing great test coverage and ensuring that perf is not worse!

LGTM!