DO NOT MERGE: experimental Windows clang-cl + TAILCALL VM lane (windows-x86_64-clang)

[luthermonson]

DO NOT MERGE — experimental Windows clang-cl + TAILCALL VM lane

Adds an additive-only build lane, platform=windows-x86_64-clang, producing
php-sdk-<ver>-windows-x86_64-clang.tar.gz: the same artifact layout and
extension set as the MSVC lane, but with PHP itself compiled by a pinned
LLVM release (22.1.8) so PHP 8.5's new ZEND_VM_KIND_TAILCALL interpreter
is selected instead of the slow ZEND_VM_KIND_CALL that every MSVC build
gets. The existing windows-x86_64 lane is untouched.

Why

Zend/zend_vm_opcodes.h picks HYBRID only under __GNUC__ && HAVE_GCC_GLOBAL_REGS — never true on win32 — so Windows has always run the
CALL VM (upstream measured 1.77x slower than HYBRID). PHP 8.5 added TAILCALL
(musttail + preserve_none, clang-only), which recovers HYBRID-class
dispatch. HAVE_MUSTTAIL is header-detected; HAVE_PRESERVE_NONE only comes
from an autoconf run-test that never runs on Windows, so no Windows PHP has
ever selected TAILCALL. This lane hand-defines it.

Measured (PHP 8.5.7 CLI, Ryzen 9 5950X, ZTS, best-of-5 hrtime)

build	VM kind	int loop 1M	mixed ref loop
MSVC 19.44	CALL (verified)	14.2 ms	4.42 ms
LLVM 22.1.8 clang-cl	CALL (verified)	13.1 ms	4.31 ms
VS-bundled clang-cl 19.1.5	TAILCALL (verified)	22.6 ms	7.07 ms
LLVM 22.1.8 clang-cl	TAILCALL (verified)	8.4 ms	2.72 ms

End to end through ePHPm (ephpm php, same loops, full extension set, both
binaries from the same ephpm commit, only PHP_SDK_PATH differing):

ePHPm build	mixed ref loop	int loop 1M
MSVC SDK (CALL)	4.43 ms	14.1 ms
clang SDK (TAILCALL)	2.73 ms (1.62x)	8.2 ms (1.72x)

Three findings that shape the design:

1. The win is the TAILCALL VM, not clang per se: clang 22's CALL build is
   only at parity with MSVC (13.1 vs 14.2 ms); switching the VM kind delivers
   the 1.55–1.7x.
2. The VS-bundled clang-cl 19 is a trap — its Zend codegen is ~45–90%
   slower than MSVC, enough to swamp the VM-kind win (verified CALL-vs-CALL,
   ZTS and NTS). Hence the pinned LLVM download with a hard version gate, not
   the VS Clang component.
3. With LLVM 22, the mixed reference loop lands within ~12% of the same loop
   on ePHPm Linux (HYBRID) — the Windows interpreter gap is essentially closed.

How the lane works

• Clones php-src at the release tag, patches win32/build/config.w32
  (toolset default vs → clang; AC_DEFINE("HAVE_PRESERVE_NONE") in the
  CLANG_TOOLSET block, gated clang ≥ 19 + x64), and feeds it to stock
  spc via --custom-local "php-src:…" — spc's Windows target hardcodes its
  configure args, so no spc fork change is required. The patch step
  hard-fails if the anchor text drifted.
• --dl-custom-local is repeated on spc build (the build phase runs its
  own downloader pass and otherwise silently replaces the patched tree with
  the stock tarball — found the hard way).
• Deps stay MSVC-built; clang-cl is MSVC-ABI-compatible. Verified end to end:
  the clang php8embed.lib links into ePHPm's unchanged
  x86_64-pc-windows-msvc build (zero ePHPm source changes).
• Consumer-header hygiene (both found building ePHPm, both fixed in the
  Package step with hard guards): the staged php_config.h/config.w32.h
  must NOT export HAVE_PRESERVE_NONE (rust-bindgen panics on libclang
  calling convention 20; MSVC consumers can't represent it either) nor the
  PHP_HAVE_BUILTIN_* defines (Zend's static-inline fast paths then emit
  __builtin_expect calls MSVC consumers cannot link). Stripping them gives
  every consumer the same portable CALL-view the MSVC-lane headers give,
  while the engine runs TAILCALL internally (zend_vm_kind() still says 5).
• VM-kind gate: the workflow extracts zend_vm_execute.obj from the
  built php8embed.lib and requires zend_vm_kind to compile to
  mov eax,5 (TAILCALL). The lane cannot silently regress to CALL.
• Never in platform=all, never in platforms_required, never gates a
  release (mirrors the -nts lanes' isolation).

Known blocker for running this in CI (pre-existing, affects the MSVC lane too)

spc v3.0.0-pgo-rc18's Windows passthru() gives children socket-type
stdout/stderr descriptors. msys git (any version — tested 2.49 and 2.55)
cannot dup socket handles as std fds: every git clone spc runs dies with
dup() in/out/err failed / cannot duplicate fd. The rc18 Windows leg has
never run in CI (fleet was down when rc18 landed) — when it does, the
existing MSVC lane will hit this too on the git-sourced artifacts
(php-micro, gettext-win, libiconv-win, libaom, …). Local validation
worked around it with a git shim that re-execs git with file-backed std
handles; the real fix belongs in the spc fork (pipe descriptors for git, or
shipping such a shim). Filed as a first-class finding, not fixed here.

Local validation performed

• go/no-go CLI experiment: MSVC vs clang19 vs clang22, CALL vs TAILCALL, ZTS
  and NTS — VM kinds proven via a zend_vm_kind() probe in each binary.
• Full lane run locally with stock spc.exe rc18 + the exact workflow patch
  logic (plus the git-shim + short-path workarounds CI won't need).
• ePHPm built against the resulting clang SDK with zero source changes;
  CLI + serve-mode benchmarks and correctness checks in the ePHPm repo
  (numbers in the lane's job comment and README).

DO NOT MERGE until: (a) the spc git/socket issue is fixed in the fork so the
lane can actually run in CI, and (b) the org decides the artifact should soak
as an opt-in lane.