Build the LLVM backend on every platform in CI

[dougchansan]

The LLVM backend had no CI coverage on macOS at all, and on Windows only under MSYS2/UCRT64 mingw GCC. The MSVC job builds the repo but configures without DOLRECOMP_ENABLE_LLVM, so src/backend/llvm is never compiled there.

An MSVC-only break therefore could not be seen by any job, and one duly landed on main:

abi_policy.cpp(15): error C3861: '__builtin_popcountll': identifier not found

mingw GCC has that builtin, so the one job that does enable the LLVM backend on Windows compiles it happily. MSVC plus the LLVM backend is the configuration a local Windows toolchain actually uses, and it was the one combination nothing built. (#31 fixes that break; this PR is what would have caught it.)

macOS was worse — nothing anywhere built the LLVM backend for Mach-O, which is how the invalid cold-section name in #26 went unnoticed.

What changed

The llvm matrix is now keyed on toolchain rather than OS, because the two Windows entries are genuinely different configurations:

os	toolchain	notes
ubuntu-latest	gcc	unchanged
windows-latest	mingw	unchanged
windows-latest	msvc	new — official LLVM 20.1.8 windows-msvc release
macos-latest	appleclang	new — Homebrew llvm@20, Mach-O object path

macOS: 29 of 32 tests gate, three are excluded

Rather than let the job sit permanently red, three tests are excluded as known Darwin gaps, each named in a comment with what enabling it would take:

• llvm_pipeline — is_native_object() knows COFF and ELF only. On macOS the pipeline emits both native Mach-O and cross-target ELF objects in the same run, so the check has to know which object is which target before it can be meaningful here. Adding a Mach-O branch fixes two of its three call sites but not the third, which reads a cross-target ELF object.
• modern_codegen — the wide return struct has a different element count under the arm64 Darwin ABI (getNumElements() == 3 does not hold).
• llvm_codegen — AArch64 disassembly assertions; symbol naming differs on Mach-O.

None of these is a regression; all three fail on main today once the build gets far enough to run them.

macOS also runs ctest -j1. Those tests share artifacts in the build directory and report an inconsistent subset of failures under -j10 — worth knowing for anyone reproducing locally.

Verification

Built and tested all four configurations locally before opening this:

configuration	result
Linux, GCC + LLVM 20.1.2	33/33 pass
Windows, MSVC 14.50 + LLVM 20.1.8	32/32 pass (with #31)
Windows, mingw + LLVM 20.1.8	unchanged from today
macOS arm64, Apple clang + LLVM 20.1.8	29/29 pass with the three excluded (with #26)

Expected state of this PR

The two new jobs will be red on main until #31 and #26 land — MSVC on the popcount break, macOS on the Mach-O cold-section name. That is the point: both are real, both are already fixed in open PRs, and neither was visible to CI before. Merge those two first and this goes green.