Add wasm_esm_integration_builtins compat flag for runtime-compiled Wasm

[guybedford]

This adds a wasm_esm_integration_builtins compatibility flag that compiles Wasm modules with the js-string builtins and imported string constants enabled, resolves #6811. Equivalent to the JS-visible options:

new WebAssembly.Module(src, {
  builtins: ['js-string'],
  importedStringConstants: 'wasm:js/string-constants',
});

V8 has no global flag for these; they are strictly per-module opt-in, so workerd-compiled modules (which never go through the JS constructor) couldn't use them. V8 now exposes WasmModuleObject::Compile with CompileOptions, so when the flag is set jsg::compileWasmModule passes:

options.builtins = v8::WasmModuleObject::CompileOptions::Builtins::kJsString;
options.imported_string_constants_module = "wasm:js/string-constants";

Since this is the single shared compile helper, it covers all runtime-compiled Wasm: import / import source in both module registries, and the deprecated Service Worker syntax wasmModule binding. The flag is plumbed through IsolateBase like the other module-related compat flags.

The js-string-builtins proposal is still in the implementation phase, so the flag is opt-in with no enable date.

Test coverage: adds a js-string-builtins.wat fixture importing the js-string length builtin and a "hello world" string constant, which only links if both features are enabled. new-module-registry-test (flag on) asserts constantLength() returns 11 across normal import, static import source, and dynamic import.source(), using query-distinct specifiers so each path gets its own compile. wasm-js-string-builtins-test (flag off, legacy registry) asserts the wasm:js-string import is treated as an ordinary unsupplied import.

[ask-bonk]

Since last review: 0 resolved, 0 still open, 0 new.
LGTM!

Not re-run: tests, api-compat, docs, compat-flags, design-simplicity, jsg-gc, kj-style, memory-safety (no author changes in their files since the last review)

---

_{Reviewed commit: b25c2849 · github run}