Temporal and Intl parsing cannot fail because the machine was busy (#3486)

[lahma]

Backport of #3486 (main: ba18893a1) to 4.x. Fixes #3485 on this branch too.

What an embedder on 4.x sees today

Temporal.PlainDate.from('2024-01-15T10:30:00') — a correct call with a valid string — can throw
System.Text.RegularExpressions.RegexMatchTimeoutException. It is not a JintException and not a
JavaScriptException: because RegexMatchTimeoutException is listed in Throw.MustPropagateHostException,
it goes straight through the script's own try/catch and reaches the host as a raw CLR exception
whose message blames "very large inputs or excessive backtracking" for a 19-character valid string.

Regex.MatchTimeout is a wall-clock deadline sampled while matching. It cannot tell "this pattern is
backtracking" apart from "this thread lost the CPU". Eight patterns in TemporalHelpers.cs and one in
IntlUtilities.cs carried 100 ms of it on this branch, byte-identical to what main carried.

Evidence on this branch, before the fix

The new test file was compiled against unfixed 4.x first, on both legs. Jint.Tests targets
net472 (which resolves Jint's net462 asset) and net10.0.

leg	before the fix	after the fix
net472 → Jint net462	Failed: 2, Passed: 19	Passed: 21, Failed: 0
net10.0	Failed: 2, Passed: 19	Passed: 21, Failed: 0

Both legs failed identically:

NoInternalParsePatternCarriesAWallClockDeadline
  Expected -1ms because TemporalHelpers.DatePattern is a fixed internal pattern over engine-supplied
  input, and a wall-clock budget on one can only ever fire spuriously — as an uncatchable CLR
  exception, but found 100ms.

EveryPatternRejectsAdversarialInputWithoutBacktrackingAwayTheAfternoon
  Expected regex.IsMatch(input) to be False because TemporalHelpers.AnnotationPattern must reject
  adversarial input, but found True.

The quadratic pattern, measured on this branch

AnnotationPattern — \[(!?)([^\]]+)\] — is quadratic on input holding no ]: each of the n start
positions consumes the rest of the string and backtracks over it. A throwaway probe drove the shipped
pattern (RegexOptions.Compiled) with '['×n, once with the 100 ms budget it ships with and once with
Regex.InfiniteMatchTimeout to read the genuine CPU cost:

input	net472 (Jint net462) with 100 ms budget	net472 genuine CPU	net10.0 genuine CPU
4 KB	RegexMatchTimeoutException	304.7 ms	1.8 ms
8 KB	RegexMatchTimeoutException	951.0 ms	1.1 ms
16 KB	RegexMatchTimeoutException	2209.5 ms	4.1 ms
32 KB	RegexMatchTimeoutException	7080.9 ms	15.6 ms

That is real backtracking, not scheduling: 2x the input costs ~3x the time on both runtimes (net10.0's
rewritten engine has a far smaller constant but the same shape — 4.1 → 15.6 ms across the last doubling).
The linear walk that replaces it costs 0.126 ms on net472 and 0.107 ms on net10.0 over 200,000 [.

It was unreachable with such input only because its sole caller hands it InstantPattern's group 14,
which that grammar already guarantees is well-formed — an argument about the caller, not a property of the
code. The probe was deleted; it is not part of this PR.

The fix

Identical to #3486, applied unmodified:

• Eight patterns in TemporalHelpers.cs and one in IntlUtilities.cs now take
  Regex.InfiniteMatchTimeout. The failure mode is removed rather than relabelled.
• The fixed-width patterns reject anything longer than the longest string they could match, before
  matching — bounds 13, 18 and 37, pinned so a widened pattern cannot outgrow its cap silently.
• AnnotationPattern is replaced by a linear walk, pinned by a test that drives the walk and the
  retired pattern over ~5,000 inputs including the two cases the pattern's backtracking decided on its
  own: [], which has no content and is not an annotation, and [!], where the optional ! is given
  back to the content.

Options.Constraints.RegexTimeout never reached these patterns and still does not — it bounds
script-supplied regular expressions, unchanged.

Divergence from #3486

• Jint.Tests on 4.x is xUnit v3, not NUnit. TemporalParsePatternBudgetTests is transcribed
  attribute-for-attribute: [Test] → [Fact], [TestCase(...)] → [Theory] + [InlineData(...)].
  Nothing else in the file changed — same assertions, same corpora, same seeds.
• docs/v5-migration.md does not exist on 4.x, so that hunk is dropped. There is nothing to
  migrate: a host that caught RegexMatchTimeoutException around Engine.Evaluate to absorb this can
  simply drop that handler.
• The engine hunks applied clean — 4.x's pattern block is byte-identical to the pre-fix main one,
  so the two source files are the same after this as they are on main.

Verification

• dotnet build -c Release — clean, TreatWarningsAsErrors on.
• dotnet test -c Release, both TFMs where the project has one:
  Jint.Tests 6,854 (net10.0) / 6,769 (net472), Jint.Tests.PublicInterface 1,500 / 1,493,
  Jint.Tests.CommonScripts 28 / 28, Jint.Tests.SourceGenerators 52 — all green, 0 failed.
• test262: 102,491 passed / 189 skipped, with 4 failures under full-solution parallel load —
  staging/sm/Array/toSpliced-dense.js and staging/sm/TypedArray/sort_large_countingsort.js, each
  ×2 for the strict/sloppy pair, each at 30–33 s, i.e. the engine's 30-second default timeout. All
  four pass in isolation in 4 s total, and none of them touches Temporal or Intl. Load flakes on a
  busy shared box, unrelated to this change.