Port normalized equivalent of YieldProcessor from CoreCLR

[kouvel]

• Port Add normalized equivalent of YieldProcessor, retune some spin loops coreclr#13670
• Port any other PRs that fix relevant issues referenced in https://github.com/dotnet/coreclr/issues/13388

[kouvel]

Nice to have, but it is not clear that it would have any significant impact, not likely to happen until a significant issue is shown to substantiate the work

[kouvel]

Monitor still does a lot of spinning and porting the CoreCLR's implementation would probably benefit most

[Suchiman]

@MichalStrehovsky is this fixed?

[MichalStrehovsky]

This is in reference to #7569 (for the future me, since I failed to call this issue out in the pull request).

I left this open because I'm not sure how important it would be to migrate off of YieldProcessorNormalizedForPreSkylakeCount to the new scheme with YieldProcessorNormalizationInfo.

E.g. we're not exposing the OptimalMaxSpinWaitsPerSpinIteration on System.Threading.Thread but instead normalize the spin number passed to RhSpinWait. That's not what CoreCLR does and I wasn't sure how much that matters.

@kouvel would know but he's out right now and this is going to get lost in his mailbox.

[kouvel]

Switching off of the pre-Skylake spin scheme may also require retuning spin-waits with large spin counts. Where applicable, perhaps that could be done one component at a time in the future along with porting the spin scheme for the component from coreclr. I don't think it's critical though.