Add ES2020+ -> ES2019 syntax-repair polyfill for Chakra Playground

[bkaradzic-microsoft]

Adds a lightweight regex-based ES2020+ -> ES2019 syntax-repair polyfill so Chakra-based BN runtimes can parse playgrounds that use modern syntax. V8/JSC runtimes already support these features natively; the polyfill self-detects and no-ops when not needed.

Changes:

• New Apps/Playground/Scripts/es2019_transpile.js - regex repair for: ?. (optional chaining), ?? (nullish coalescing), numeric separators (incl. hex), ||= &&= ??= (logical assignment). Top-level var __bnTranspileES2019 exposes the helper.
• Apps/Playground/Scripts/validation_native.js - evalWithFallback catches SyntaxError and retries once with repaired source.
• Apps/Playground/CMakeLists.txt - adds es2019_transpile.js to SCRIPTS list.
• Apps/Playground/Shared/AppContext.cpp - loads es2019_transpile.js before fetch_polyfill.js.
• Apps/Playground/Scripts/config.json - re-enables 1 test (idx 403 custom-handling-of-materials-for-render-target-pass); rewrites reason on 25 remaining-excluded tests with their post-polyfill state.

Caveat: Polyfill is parse-only - ?. rewrites to . so null targets raise TypeError at runtime instead of short-circuiting. 25 tests remain excluded for: 9 runtime TypeErrors from ?. -> . semantic divergence, 4 missing ADDONS module, 8 asset/url errors, 4 ES2022 private fields not handled by the polyfill.

Landing context

This PR is one of 8 splits from the proven CI-green combined preview in draft PR #1702 (see #1702 for the full intended end-state and verified CI run 26044922430).

Recommended landing order

Tier 1 - parallel-reviewable, no source conflicts:

1. Fix ExternalTexture_OpenGL throw-stubs to avoid MSVC C4702 under /WX #1703 - ExternalTexture C4702 build fix
2. Document accurate root cause for post-#1695 pixel-diff fallouts #1704 - config.json reason rewrites (3 entries)
3. Document accurate root cause for 17 subtle pixel-diff tests #1705 - config.json reason rewrites (17 entries)

Tier 2 - sequential, each touches Apps/Playground/CMakeLists.txt SCRIPTS list + Apps/Playground/Shared/AppContext.cpp LoadScript order; rebase the next branch after the previous merges:

4. Add File/Blob/FileReader polyfill for Playground (re-enables 19 GLTF tests) #1706 - File/Blob/FileReader polyfill (largest test impact: 19 re-enables)
5. Add fetch() polyfill over XMLHttpRequest for Playground #1707 - fetch polyfill
6. Add DOM globals polyfill + native AbortController for Playground #1708 - DOM globals + native AbortController + Android CMake link
7. Add ES2020+ -> ES2019 syntax-repair polyfill for Chakra Playground #1709 - ES2020+ -> ES2019 transpile polyfill
8. Add cubemap auto-expand polyfill for Playground (re-enables 7 PBR tests) #1710 - Cubemap auto-expand polyfill (loaded after babylon.max.js)

Reference policy reminder

Reference PNGs across all 8 PRs come from Babylon.js; never re-baked by BN. Combined diff: 0 PNGs.

[ryantrem]

Why are we doing this with a custom script rather than just using babel or swc or something?

[bkaradzic-microsoft]

Fair point. Honest assessment of the tradeoff:

• The custom regex polyfill runs inside the Chakra host at parse-failure time, so a Node-side build tool (babel CLI / swc CLI) wasn't directly usable. The runtime-in-host constraint left us with @babel/standalone (~1 MB shipped + parsed by Chakra at startup), swc-wasm (Chakra doesn't support WASM), or this regex stopgap.
• The regex is semantically incomplete — ?. rewrites to . so null?.foo throws TypeError instead of returning undefined. That's 9 of the 26 affected tests still excluded because of this divergence, plus 4 more for ES2022 private fields. So this polyfill unlocks only 1 test out of 26.
• The cost/benefit of "+114 lines for +1 test, with a semantic footgun baked in" is too thin to justify cementing the regex approach.

Closing this PR. Filed #1711 to investigate @babel/standalone properly (measure the actual size/startup cost, prototype, compare against alternatives, decide). If that lands, it would unlock the 9 ?. tests + 4 ES2022 tests correctly, which is a much better story than what this PR achieves.

Thanks for pushing back.

[bkaradzic-microsoft]

Closing per discussion above. Pursuing #1711 instead.