Simplify build configuration

[fhanau]

• Use ubuntu-24.04 runner so we get a more recent clang version
• Use native arm64 build, getting rid of zig
• Remove setup steps for dependencies that are already installed on the runner images
• CLANG_ENABLE_ARCMT is deprecated, don't attempt to disable it

[fhanau]

Looks like the Windows build is failing for Windows reasons (according to Sonnet):

The exit code is still the important clue: 3221225785 = 0xC0000139 = STATUS_ENTRYPOINT_NOT_FOUND ("The procedure entry point ... could not be located in the dynamic link library ..."). That's a DLL-loading failure, not a compile/parse error — and it's happening on llvm-min-tblgen.exe, a host tool that Ninja just linked moments earlier in this same build and is now invoking repeatedly (once per target .td file) in parallel. All three failures shown are the identical failure on the identical tool — the specific .td file being processed is irrelevant.
With clang-cl/lld-link ruled out, the most plausible remaining explanation is a well-documented flake on GitHub's windows-latest runners: Windows Defender's real-time scanning race with freshly-written executables. When link.exe finishes writing llvm-min-tblgen.exe and Ninja immediately spawns several parallel instances of it (this build has ~3146 total targets and heavy parallelism), Defender's on-access scan can grab/lock the file while it's still being finalized, causing the loader to see an inconsistent image — which surfaces as exactly this "entry point not found" error rather than a clean "file in use" error. This is a known issue reported by several large C++ projects (LLVM, Chromium, Rust) building on GitHub-hosted Windows runners with Ninja.

But maybe that's fine since workerd doesn't use the clang-tidy Windows binary anyway? I have no reason to assume that the changes here are responsible for the failure.

[npaun]

If it's a flake as the clanker says, maybe we can re-run your test job and see if it disappears?

[npaun]

Also why the fuck would GitHub be running Windows Defender in CI? Can we nuke it somehow? If this is true I think we can make things way faster.

[fhanau]

Turns out that explanation was wrong – the actual issue appears to be actions/runner-images#11102, the latest commit contains a workaround and the Windows job passed https://github.com/cloudflare/workerd-tools/actions/runs/33019715585/job/98346819585