Distinguish an optional-chain short circuit from a genuine undefined

[lahma]

Jint signalled "this optional chain short-circuited" by returning the JsValue.Undefined singleton and then testing for it with ReferenceEquals. That is indistinguishable from a link that legitimately produced undefined, so several expressions silently returned undefined where they must throw:

(0, undefined)()          // returned undefined; must throw TypeError
new.target()              // returned undefined; must throw TypeError
({})?.a['b']              // returned undefined; must throw TypeError
(a?.b).c                  // returned undefined; must throw TypeError  (a === null)

Per 13.3.9.1 a chain short-circuits only at the ?. whose own base is nullish. new.target() was caught up in it because Engine.GetNewTarget() returns thisEnvironment.NewTarget ?? JsValue.Undefined, which then tripped the sentinel test in JintCallExpression.

There was a second, independent bug on the same code path: JintMemberExpression short-circuited whenever

baseValue.IsNullOrUndefined() && (_memberExpression.Optional || _objectExpression._expression.IsOptional())

i.e. because the object expression merely contained a ?. somewhere, not because this link had one. That disjunct is what made ({})?.a['b'] and (a?.b).c return undefined.

The fix

A dedicated internal sentinel, OptionalChainShortCircuit — a JsValue with Types.Empty whose ToObject() throws, so it claims no JavaScript type and cannot masquerade as a value if it ever escaped.

Whether a link emits the sentinel or a real undefined is decided at build time: a member/call node calls EnableShortCircuitPropagation() on its object/callee only when that child is part of the same chain (a ChainExpression child ends the chain, which is exactly what parentheses mean). A link nobody asked returns JsValue.Undefined, so there is no conversion step at the boundary to get wrong.

Containment is structural rather than by convention: every parent that asks consumes the sentinel in the statement immediately following the child's Evaluate, so it never travels more than one edge, is never stored, never becomes a Reference base, and never reaches engine.GetValue. The four fast lanes that would reach a child by some route other than Evaluate are all gated on !_objectExpressionCanShortCircuit, which is exactly complementary to the condition that enables propagation.

The IsOptional() disjunct is removed.

Performance

Nothing added on the non-optional path, and the member link's own test got cheaper: an IChainElement type test became a bool field read, tested first. The additions are one bool field on each of two node types and one internal virtual slot called only during handler-tree construction.

Tests

Jint.Tests/Runtime/OptionalChainShortCircuitTests.cs — 10 tests, 5 failing against unfixed code, plus positive cases (undefined?.a, null?.a?.b, deep mixed chains) and a test that a short-circuited chain's result is an ordinary undefined for typeof, ===, String(), ??, JSON.stringify, spread and computed keys.

language/expressions/optional-chaining/** (76 generated cases) unaffected.

Frees three staging/ exclusions: class/newTargetDVG.js, expressions/optional-chain.js, extensions/extension-methods-reject-null-undefined-this.js. The exclusion comment claimed the last of these needed SpiderMonkey's toSource extension and was unfixable — that was wrong, and instructively so: toSource being absent is precisely what makes Object.prototype.toSource undefined, which drove (0, Class.prototype[method])() into the buggy call path. The missing extension was the trigger, not the blocker.

Refs #3021.