What does this PR do?

Fixes #8745, fixes #15492, fixes #15929, fixes #16763, fixes #18115

console.log(String.raw`æ™`); // -> "æ™" instead of "\u00E6\u2122"
console.log(/æ™/.source); // -> "æ™" instead of "\u00E6\u2122"

Changes ascii_only to prefers_ascii. It will try to emit mostly ascii, but if a non-ascii character is encountered in a tagged template, it will emit it. Updates execution to scan the file to see if it contains any non-ascii and if it does, load it as utf-8 instead.

This should be benchmarked to see what the performance cost is.

TODO:

• Store the file as utf-16 in the runtime transpiler cache (caches large transpiled files)
• Store the file as utf-16 in the standalone module graph (for bun --compile)
• Figure out what to do about a comment containing a non-ascii characters. Should they mark the whole file as non-ascii, or should the non-ascii characters be removed from the output, or should the bytes be passed to JavascriptCore as latin-1 if it's only a comment? A non-ascii comment is probably much more likely than a non-ascii character within a tagged template literal.

Alternate solution is to add a polyfill in js_parser.zig or do some injection into jsc's parsing logic:

let _0;
function _taggedTemplateLiteral(e, t = e.slice(0)) {
  return Object.freeze(Object.defineProperties(e, { raw: { value: Object.freeze(t) } }));
}

myfn`abc${def}ghi`
// =>
myfn(_0 ??= _taggedTemplateLiteral(["abc", "ghi"]), def)
// or (without helper):
myfn(_0 ??= Object.freeze(Object.defineProperties(_0 = ["abc", "ghi"], { raw: { value: Object.freeze(_0) } }));

Benchmarks

• b61002945fceed12b28cfbdedafee778/tmp hyperfine "bun-latest a.js" "bun a.js" "bun-latest no_unicode.js" "bun no_unicode.js" --warmup=5
• A 478mb // @bun file is slowed down by 6ms (out of 1000ms) (about a 0.6% slowdown)
• Adding a single unicode character to a // @bun file slows it down by ~1.21x because it has to convert utf-8 to utf-16
  before jsc can parse the file