[llvm] [CMake] Correctly handle LLVM_ENABLE_RUNTIMES in targets (PR #69869)

[Petr Hosek via llvm-commits]

petrhosek wrote:

@ldionne I ran into this issue when trying to build [LLVM libc in the bootstrapping build](https://reviews.llvm.org/D155337). I need to include `libc` in `LLVM_ENABLE_RUNTIMES` to ensure that the host tools used by libc—that is `libc-hdrgen`—are built, but I only want build `libc` for the`riscv32-unknown-elf` target so I exclude it from all `RUNTIMES_<target>_LLVM_ENABLE_RUNTIMES` (with the exception of `RUNTIMES_riscv32-unknown-elf_LLVM_ENABLE_RUNTIMES`).

The issue is that the logic in runtimes prior to this patch would always iterate over the global `LLVM_ENABLE_RUNTIMES` and set up the proxy targets for the child builds. Concretely, in my example `libc` would depend on `libc-x86_64-unknown-linux-gnu` which is a proxy for the `libc` target in the `runtimes-x86_64-unknown-linux-gnu-bins` build, except that there's no `libc` target in that build because `RUNTIMES_x86_64-unknown-linux-gnu_LLVM_ENABLE_RUNTIMES` doesn't include `libc` and that leads to a build failure.

When we first implemented the bootstrapping (aka runtimes build), we only supported the global `LLVM_ENABLE_RUNTIMES` as the assumption was that every `target` would build the same set of runtimes, which is not the case in practice so we introduced support for `RUNTIMES_<target>_LLVM_ENABLE_RUNTIMES` but we never really considered interactions between the two which is what this issue is about.

@JDevlieghere sorry about the breakage, that was unintentional. I'll try to reproduce your failure locally and see if it's a problem with this change.

https://github.com/llvm/llvm-project/pull/69869