Compiler launchers are not propagated to runtimes and builtins sub-builds

### Summary

Compiler launchers set on the top-level build are not forwarded to the runtimes and compiler-rt builtins sub-builds, so a compilation cache configured for an LLVM build does not cover those compiles. They do not appear as cache misses or as uncacheable — they never reach the cache at all, which is why the gap is easy to miss.

`LLVM_CCACHE_BUILD` is affected too, by a different mechanism.

### Why it happens

Each entry in `LLVM_ENABLE_RUNTIMES`, and compiler-rt's builtins, is configured as a separate CMake project through `llvm_ExternalProject_Add`. Two separate paths both stop at the project boundary:

1. `CMAKE__COMPILER_LAUNCHER` is not among the variables `DEFAULT_PASSTHROUGH_VARIABLES` forwards — that list carries dependency-discovery variables (`ZLIB_*`, `CURL_*`, `Python3_*`) only.
2. `LLVM_CCACHE_BUILD` on non-Windows hosts sets the `RULE_LAUNCH_COMPILE` global property, which is scoped to the top-level project.

### Impact

RelWithDebInfo build of `clang;clang-tools-extra;lld;polly;mlir;bolt` with runtimes `compiler-rt;libcxx;libcxxabi;libunwind;openmp`, all targets, gcc 13.3:

| | compilations |
| --- | --- |
| top level (launcher applied) | 6734 |
| runtimes sub-build | 840 |
| compiler-rt builtins sub-build | 303 |

1143 of 7877, or **14.5% of the build**, compiles uncached.

### Reproducing the `LLVM_CCACHE_BUILD` half

Configure with `-DLLVM_CCACHE_BUILD=ON -DLLVM_ENABLE_RUNTIMES=libunwind`, then `ninja runtimes-configure`:

| | compile rules carrying ccache |
| --- | --- |
| top-level `CMakeFiles/rules.ninja` | 254 |
| runtimes sub-build `CMakeFiles/rules.ninja` | 0 |

The sub-build's `CMakeCache.txt` has no launcher entry either.

One caution if you reproduce this: do not name the build directory something containing "ccache". `grep -i ccache` then matches the path and reports thousands of false hits. That cost me a wrong answer on the first attempt.

### Reproducing the launcher half

Configure with `-DCMAKE_C_COMPILER_LAUNCHER=ccache -DCMAKE_CXX_COMPILER_LAUNCHER=ccache -DLLVM_ENABLE_RUNTIMES=libunwind`, then `ninja runtimes-configure`. The sub-build's `CMakeCache.txt` holds no launcher entry, and its `build.ninja` has no `LAUNCHER` edges.

Note that the launcher lands as a per-edge `LAUNCHER` variable in `build.ninja`, not in `rules.ninja`, so grepping the wrong file suggests the fix does not work when it does.

### Existing workaround

Repeating the flags in `RUNTIMES_CMAKE_ARGS` and `BUILTINS_CMAKE_ARGS` works today, and is what Debian's `llvm-toolchain` packaging does. It is easy to apply to one sub-build and forget the other, which is how I found this.

`LLVM_CCACHE_BUILD` has no workaround of that shape, because the user never sets a launcher variable to forward. Passing `-DCMAKE_C_COMPILER_LAUNCHER=ccache` instead of `LLVM_CCACHE_BUILD=ON` does work.

### Note on fixing the `LLVM_CCACHE_BUILD` half

It is not a matter of adding it to the same forwarding. `RULE_LAUNCH_COMPILE`'s value embeds environment assignments (`CCACHE_CPP2=yes ... ccache`) which work only because that command goes through a shell. `CMAKE__COMPILER_LAUNCHER` is exec'd as argv and would break on them. It needs its own change.

---

*Filed with the assistance of an AI coding agent (Claude Opus 5, via Claude Code), per the [AI tool policy](https://llvm.org/docs/AIToolPolicy.html). The agent ran the measurements and drafted this text; I reviewed it and am accountable for it.*

Start by tracing llvm_ExternalProject_Add and DEFAULT_PASSTHROUGH_VARIABLES, then reproduce with runtimes-configure using the launcher flags described in the issue. Done means runtime and compiler-rt builtins sub-builds receive the compiler launchers, with separate validation for LLVM_CCACHE_BUILD and the generated CMake/Ninja configuration.

Written by the indexing model from the issue text.