[JSC] Implement `%RegExpStringIteratorPrototype%.next` in C++

1452a43

JSC's DFG and FTL tiers inline frequently called builtins as first-class IR nodes, letting the compiler reason about types and elide JS call overhead. The "primordial exec" guard is a watchpoint: when RegExp.prototype.exec is still the original native implementation, the fast path calls execInline directly, bypassing the observable JS exec call. If exec is ever replaced — even mid-iteration after the call site has tiered up — the watchpoint fires and JSC must OSR-exit to the slow path.

JSTests/stress/regexp-string-iterator-next-adversarial.js

+    class Species extends RegExp {
+        static get [Symbol.species]() {
+            return function (p, f) {
+                matcher = new RegExp(p, f);
+                if (configure)
+                    configure(matcher);
+                return matcher;
+            };
+        }
+    }

This commit migrates %RegExpStringIteratorPrototype%.next from a JavaScript builtin (now deleted) to a native C++ implementation, adding a new RegExpStringIteratorNext DFG node compiled inline in both DFG and FTL tiers, with a fast path that calls RegExpObject::execInline directly when the iterated RegExp still holds the primordial exec.

Significance

Every String.prototype.matchAll loop now routes through a new JIT-inlined C++ hot path with watchpoint-gated fast/slow branching, yielding up to ~19% throughput improvement on matchAll benchmarks.

Audit directions

The new node carries three distinct correctness hazards. Watchpoint race / late deoptimization: the fast path checks primordial-exec status before dispatching to execInline; if an exec replacement or GC event invalidates the watchpoint between the guard and the use of the result, the iterator could yield results from the wrong exec implementation. The adversarial test exercises mid-iteration exec swaps, but real OSR-exit timing in the DFG/FTL pipeline is harder to control. Inline result-object shape: the fast path inline-allocates {value, done} objects using iteratorResultObjectStructure; if any caller can observe or modify the structure, the assumption may not hold — check createIteratorResultObject and iteratorResultObjectStructureConcurrently. Unicode boundary advancement: advanceStringIndex moved from RegExpPrototype.cpp to RegExpObjectInlines.h and is now called directly from execInline; surrogate-pair boundary bugs in this new call site could cause off-by-one advances, leading to infinite loops or missed matches with sticky/global Unicode regexps.