Consolidate polyfills and conditional compilation; fix seekability defects

[lahma]

What

Consolidates Parlot's conditional-compilation surface, gives the downlevel target frameworks test
coverage for the first time, and fixes three defects that only became visible once the guards were
readable.

Parlot targets net472;netstandard2.0;net8.0;net10.0. Over that exact set, NET, NETCOREAPP,
NET6_0_OR_GREATER, NET7_0_OR_GREATER and NET8_0_OR_GREATER all denote the same two frameworks.
All five spellings were in use.

	before	after
#if / #elif blocks in src/	60	41
distinct TFM guard spellings	8	3 (two distinct sets)
target frameworks executed by tests	net8.0, net10.0	net8.0, net10.0, net472
tests run	1723	2465

Commits

Each commit records whether it moves the net10.0 leg. Reviewable in order.

1. Normalize the guard vocabulary. Every TFM guard becomes NET8_0_OR_GREATER. Set-identical
   over the actual TFM list — verified with ilspycmd -il, whose output is byte-identical before and
   after on both the newest (net10.0) and the oldest (net472) leg.
2. net472 test leg + Windows CI job. Parlot.Tests targeted only net8.0/net10.0 and CI ran
   ubuntu-only, so no test in the repository had ever executed a downlevel code path. The leg is
   OS-conditioned in the csproj, so dotnet build / dotnet test are unchanged on Linux and Windows
   picks it up for free. Three portability fixes outside src/Parlot that this surfaced are in the
   same commit.
3. Delete Polyfill.cs. Both members had zero call sites. Append<T> shadowed
   Enumerable.Append — which ships in netstandard2.0 and .NET Framework 4.7.1+ — with a version
   that copies the whole source into a List<T> first.
4. Backfill missing BCL members as C# 14 extension members. Numbers.cs had thirteen #if/#else
   pairs whose two branches said the same thing twice. It is now written as if the project only
   targeted net10.0, with the downlevel bodies in src/Parlot/Polyfills/. 14 blocks become 1.
5. Delete unreachable Half handling. An #if NET8_0_OR_GREATER branch nested inside the
   #else of #if NET8_0_OR_GREATER, plus the class it was the only consumer of.
6. Fix Terms.AnyOf(ReadOnlySpan<char>) losing CanSeek and wrapping SkipWhiteSpace twice.
7. Fix ListOfChars never being seekable downlevel.
8. Use char.IsAsciiDigit/IsAsciiHexDigit for the digit predicates.

Defects fixed

Terms.AnyOf(ReadOnlySpan<char>) was not seekable on net8.0+. It delegated to
Terms.AnyOf(SearchValues<char>), and that constructor cannot recover the source chars, so it left
CanSeek = false and ExpectedChars empty. Literals.AnyOf, Terms.NoneOf and the net472 #else
leg were all seekable. It also produced SkipWhiteSpace(SkipWhiteSpace(literal)).

ListOfChars was never seekable at all on net472/netstandard2.0: the constructor tested the
fields _minSize and _negate before assigning them from the parameters, so the condition was
always 0 > 0 && !false. Found by the new seekability test on the new net472 leg — the first defect
that leg caught, and one the test suite could not previously reach.

Benchmarks

char.IsAscii* versus SearchValues.Contains for the digit sets (MediumRun, 15 iterations ×
2 launches). DecimalDigits is "0123456789" and HexDigits is "0123456789abcdefABCDEF", so the
BCL predicates are exact equivalents, asserted over all 65536 char values by two new tests:

Method	Mean	Error	StdDev
SearchValuesContains_IsDecimalDigit_True	0.1911 ns	0.0066 ns	0.0092 ns
SearchValuesContains_IsDecimalDigit_False	0.1945 ns	0.0094 ns	0.0132 ns
IsAsciiDigit_True	0.0159 ns	0.0165 ns	0.0246 ns
IsAsciiDigit_False	0.0138 ns	0.0231 ns	0.0323 ns
SearchValuesContains_IsHexDigit_True	0.1163 ns	0.0215 ns	0.0309 ns
SearchValuesContains_IsHexDigit_False	0.2146 ns	0.0670 ns	0.0983 ns
IsAsciiHexDigit_True	0.0000 ns	0.0000 ns	0.0000 ns
IsAsciiHexDigit_False	0.0074 ns	0.0061 ns	0.0089 ns

The IsAscii* rows sit at the resolution floor — they inline to a couple of instructions — so read
them as "free" rather than as exact values. IsIdentifierStart/IsIdentifierPart are deliberately
unchanged: they have no BCL equivalent, and the pre-existing benchmark in the same file shows
SearchValues.Contains is the best option for those sets.

For Terms.AnyOf, a benchmark comparing the single- and double-wrapped shapes is included. The
direction is consistent (7 of 8 measurements favour the single wrap, ratios 1.02–1.40) but the
magnitude is within noise on my machine, so the argument for that commit is the lost seekability and
the divergence from every sibling factory, not the layer cost.

Declined polyfills

Recorded with a comment at each site so a later sweep does not undo them.

API	Why not
SearchValues<char>	Missing type, and a polyfill degrades IndexOfAny/IndexOfAnyExcept to a per-char loop — a regression in Scanner's hottest loops. The #else legs there are different algorithms, not naive scans.
INumber<T>	Missing type; gates a whole modern-only lane and a public generic constraint.
Half	Missing type downlevel.
string.GetHashCode(span, StringComparison) for TextSpan.GetHashCode	The API is .NET Core 2.1+, and so is the string.GetHashCode(StringComparison) a naive polyfill body would call. A correct downlevel body allocates the string anyway — which is what the #else already does, without the indirection.
new string(ReadOnlySpan<char>)	Constructors cannot be extension members; the one call site now uses ToString().

Verification

• dotnet build -c Release — all four legs, 0 warnings (TreatWarningsAsErrors is on).
• dotnet test -c Release — 2465 passed, 0 failed, across net472 / net8.0 / net10.0.
• ilspycmd -il diff on src/Parlot for net10.0 and net472 between commits. Commits 1 and 2 leave
  both legs byte-identical. Commit 4's only modern-leg change is the aggressiveinlining flag now on
  ThrowHelper.ThrowIfNull, which had been a plain non-inlined wrapper.
• Benchmarks target net10.0 only, so a commit leaving that leg's preprocessed source identical is not
  measurable by this repository; the IL diff is the evidence for those commits.

Notes for follow-up (not in this PR)

The whole NumberLiteralBase<T> family in Fluent/NumberLiteralBase.cs is only reachable from the
#else leg of NumberLiterals.CreateNumberLiteralParser<T>, so net8.0/net10.0 compile it in and
never construct it. Guarding the family with #if !NET8_0_OR_GREATER would drop ~13 types from the
modern assemblies, but it is a larger diff than belongs here.

---

🤖 Generated with Claude Code