Implement native clang launcher

[sbc100]

Implement Phase 1 of the native launcher design document. Provides
high-performance native C++ compiler drivers (emcc, em++) using C++20
that directly invoke Clang for compile steps (-c, -S, -E) and seamlessly
fall back to python (emcc.py / em++.py) for link steps or complex
post-processing options.

This tool completely replaces both the windows-specific pylauncher and
the shell/bat entry points created by create_entry_points.py

These new binaries are currently optional since create_entry_points.py
can still be used instead.

Tested using embuilder build libc --force (compiling 1,075
files sequentially with EMCC_CORES=1, EMCC_USE_NINJA=0, and
EMCC_BATCH_BUILD=0). Note that this is likely an outlier since
its perfectly suited to demonstrating to speedup from this change (i.e.
lots of small source files and no linking).

Platform	Before (Python Baseline)	After (Native Launcher)	Improvement	Speedup
Linux	181.96 s (169.3 ms/file)	64.82 s (60.3 ms/file)	-117.14 s (-109.0 ms/file)	2.81x
Windows	343.90 s (319.9 ms/file)	105.12 s (97.8 ms/file)	-238.78 s (-222.1 ms/file)	3.27x
macOS	162.08 s (150.6 ms/file)	64.73 s (60.1 ms/file)	-97.35 s (-90.5 ms/file)	2.50x

See: #26453

[dschuff]

Here are some high level comments:

1. Do we need response file support? Super long command lines are more common at link time, but the windows cmdline length limit is pretty low, so maybe a long path with a few include directives would be enough to push us over even at compile time.
2. If we are using C++20, we could use std::string_view instead of std::string in a lot of places to avoid a lot of allocations and copies in string operations, e.g. is_emscripten_only_warning, is_dash_s_setting, and other places. I got a bunch of other similar suggestions from Gemini for how to reduce allocations and redundant filesystem operations that might be worth considering to reduce overhead on startup.

[sbc100]

I think once we land this and we start using it everywhere we can just remove the old shell/bat/ps1/pylauncher launchers.

[dschuff]

These can use std::string_view instead of std::string, and can be backed by the static C strings used in the initializers.
Gemini suggested even going further and using std::array instead of unordered_set, keeping them sorted, and use std::binary_search for the lookups. Not sure that's worth it though, it seems error-prone.

[sbc100]

I feel like this PR looking pretty good now.

I've been back and forth with the AI agents reviewing the code mulitple times, with particular focus on any possible behaviour differences with the old pylauncher and/or run_python scripts.