fix(build): run the target-attribute probe on musl (#51)

[luthermonson]

Closes #51.

Every musl x86_64 SDK since 8.3.31 has shipped with /* #undef HAVE_FUNC_ATTRIBUTE_TARGET */, so PHP fell back to portable C for SHA-NI, PCLMUL (CRC32) and AVX2. The CFLAGS override in 43267a7 fixed this on the glibc lane and never did anything on Alpine.

Root cause — not CFLAGS

php-src's own configure.ac skips the probe on musl:

dnl Checks for GCC function attributes on all systems except ones without glibc
AS_CASE([$host_alias], [*-*-*android*|*-*-*uclibc*|*-*-*musl*|*openbsd*], [true], [
  AX_GCC_FUNC_ATTRIBUTE([ifunc])
  AX_GCC_FUNC_ATTRIBUTE([target])
])

$host_alias holds the canonical triple x86_64-pc-linux-musl even though nothing passes --host, so on Alpine the case matches and both probes are skipped — config.log has no ax_cv_have_func_attribute_target line at all and php_config.h keeps the #undef.

The exclusion exists for ifunc, which musl genuinely lacks. target was swept into that same exclusion, but it is a pure compiler feature with no libc dependency — the target probe links with zero stderr on Alpine gcc 13.2 under the exact build CFLAGS. target alone is what selects the non-ifunc, MINIT-resolved SIMD paths (ZEND_INTRIN_*_FUNC_PTR in Zend/zend_portability.h, PHP_HASH_INTRIN_SHA_RESOLVER in ext/hash/php_hash_sha.h).

This looks like an upstream php-src bug — target does not belong in the ifunc exclusion. Working around it downstream for now; flagging rather than filing upstream.

Fix

Inject AX_GCC_FUNC_ATTRIBUTE([target]) unconditionally into configure.ac, leaving ifunc gated as php-src intends.

The patch goes into the php-src mirror tarball before spc sees it, not the extracted tree: spc download only downloads, and spc build force-extracts, so there is no window between the two commands where /build/source/php-src exists to patch — an earlier attempt that patched the extracted path failed in CI with configure.ac: No such file or directory. spc build is pinned to that same tarball with --dl-custom-url so the build phase doesn't re-resolve php-src to php.net (which would discard the patch and fail the upstream SHA256 against our repacked tarball).

The x86_64 intrinsics guard is now a hard error on musl too, not a warning.

Verified (artifacts, not job status)

Branch dispatch to v8.5.9-musl51 (tag suffix, since deleted), then inspected the real CI artifacts:

	shipped 8.5.9 musl	this PR, musl	this PR, gnu
HAVE_FUNC_ATTRIBUTE_TARGET	undef	1	1
HAVE_FUNC_ATTRIBUTE_IFUNC	undef	undef (correct)	1
SHA256_Transform_shani	absent	present	present
crc32_x86_simd_update	—	present	—
lib/*.a / libstdc++.a	37 / no	38 / yes	38 / yes

gnu is unchanged in behaviour (the added probe hits the autoconf cache).

Follow-up

Every shipped musl x86_64 tarball needs a rebuild once this merges: 8.3.32 (gnu+musl), 8.4.23, 8.4.24, 8.5.8, 8.5.9 musl, plus 8.3.33 musl (has libstdc++.a from #50 but still no SIMD).