Build clang-tidy with plugin support and publish plugin headers

[guybedford]

This enables workerd to ship its JsgLint clang-tidy plugin against the workerd-tools-built clang-tidy binary.

Two coordinated changes:

• build/llvm/common.args flips LLVM_ENABLE_PLUGINS=ON, CLANG_PLUGIN_SUPPORT=ON, and adds LLVM_ENABLE_RTTI=ON. Without these the clang-tidy binary neither exports its symbols for dlopen resolution nor emits the typeinfo records that an out-of-tree plugin's vtable references, and clang-tidy --load=... fails.

• The LLVM workflow gains a packaging step that, when the requested target contains clang-tidy, builds a per-platform llvm-<version>-<os>-clang-tidy-dev.tar.xz asset. It contains the headers needed to compile an out-of-tree plugin against this exact build:

  clang/include/{clang,clang-c}/**
  llvm/include/{llvm,llvm-c}/**
  build/include/**                   # generated config headers
  build/tools/clang/include/**       # generated clang config headers
  clang-tools-extra/clang-tidy/**.h  # plugin API (only in the source tree)
  

  Layout mirrors the LLVM source tree, so a consumer just adds -I clang/include -I llvm/include -I build/include -I build/tools/clang/include -I clang-tools-extra. Generated headers under build/ are platform-specific, hence one tarball per matrix entry.

The consuming workerd side (build/tools/clang_tidy/plugin/BUILD.headers) already expects this layout; once a release is cut with this workflow change, the temporary new_local_repository pointing at a hand-built LLVM tree gets replaced with a github_release entry in build/deps/build_deps.jsonc.

Verified the workflow's packaging step locally by mirroring it against a hand-built LLVM 22 source/build tree and confirming that bazel build //build/tools/clang_tidy/plugin:JsgLint.so in workerd consumes the resulting layout cleanly.