Fix Regex.EnumerateSplits ranges for capture groups, RightToLeft and empty matches

[SimonCropp]

Bug

The ValueSplitEnumerator polyfill (below net9.0) was built on Regex.Split and then tried to map the returned strings back to ranges. That goes wrong whenever Split does not correspond one-to-one with the gaps between matches:

• Capture groups: Split includes captured text in its result, so new Regex("(-)").EnumerateSplits("a-b") yielded 0..1 2..3 3..4 (the last range is outside the 3 character input) instead of 0..1 2..3.
• RegexOptions.RightToLeft: "," over "a,b,c" yielded 0..1 1..2 2..3 instead of 4..5 2..3 0..1.
• Empty matches with RightToLeft came back in left-to-right order.

Fix

ValueSplitEnumerator now walks the matches lazily with Match/NextMatch and yields the range between consecutive matches, honouring count (the final permitted range is the remainder of the input) and startat, and walking from the end of the input for RightToLeft. Overloads without an explicit startat now start at the end of the input for RightToLeft regexes, as the BCL does.

Test

Added to PolyfillTests_Regex.cs, asserting the exact ranges (expected values taken from the real BCL): EnumerateSplits_CaptureGroups_NotIncluded, EnumerateSplits_RightToLeft, EnumerateSplits_CountAndStartat_Ranges and EnumerateSplits_EmptyMatches. Three of the four failed on net48 and net8.0 before the fix; all pass on net48 and net8.0 (polyfill) and net10.0 (BCL) after it.

Note: count: 1 is deliberately not covered. The BCL currently throws ArgumentOutOfRangeException from MoveNext in that case, which looks like a runtime bug; the polyfill returns the whole input as a single range.