Build win-arm64 libClangSharp with clang-cl to match the LLVM release ABI

[tannergooding]

What

Builds the win-arm64 libClangSharp shim with the LLVM release's own clang-cl (via -G Ninja) instead of MSVC, so the shim's C++ record layouts match the clang-built LLVM binaries it links against.

Why

The official LLVM release binaries are clang-built. On Arm64, clang and MSVC disagree on the record layout of over-aligned non-POD base classes — e.g. clang::TemplateSpecializationType (TypeWithKeyword + FoldingSetNode, where the Type base is alignas(16)):

• clang rounds the over-aligned base up to a full slot → later base at offset 32, Template at 40.
• MSVC-Arm64 packs the next base into the over-aligned base's tail padding → later base at 24, Template at 32.

So an MSVC-built shim reads members of clang-built types at the wrong offset and returns garbage — clangsharp_Type_getTemplateName yields CX_TNK_Invalid, which surfaces as the windows-arm64 CI failures on TemplateNameTest / DependentTemplateBaseTest. This is a long-standing MSVC-vs-clang ABI disagreement specific to the aarch64-pc-windows-msvc triple (reproduces across every MSVC Arm64 and clang version tested); win-x64 layouts agree, so only win-arm64 needs the change.

Changes

• scripts/build.ps1 — route win-arm64 libClangSharp through Ninja + the release's clang-cl (imports the VS dev environment via vcvarsall, puts the LLVM bin on PATH). win-x64 keeps using MSVC.
• sources/libClangSharp/CMakeLists.txt — generalize the diaguids.lib repoint (which works around the absolute path LLVM bakes into LLVMExports.cmake) to also apply under Ninja + clang-cl, sourcing the VS root/arch from VSINSTALLDIR and the compiler arch id when the VS-generator variables are absent.
• README.md — document the win-arm64 clang-cl special-casing.

The interim skip guards for TemplateNameTest / DependentTemplateBaseTest (issue #806) stay until the native package is regenerated and republished with this fix.

Validation

Built the shim locally on an Arm64 box via the real scripts/build.ps1 -regeneratenative path (fresh build dir, simulated the LLVM build-machine diaguids path to confirm the repoint), binplaced the result, and ran both previously-failing tests: TemplateNameTest passes and DependentTemplateBaseTest is 8 passed / 0 failed (was 8× Debug.Fail).