cpufeatures: fix x86 CPUID and XSAVE state checks

[eslerm]

Closes #1510

1. Guard CPUID queries by max basic leaf. CPUID(1) and CPUID(7, N) were
queried unconditionally. Per the SDM a leaf above CPUID(0).EAX returns the
highest supported leaf's data, which check! then reads as feature bits. The
leaf 7 rows carrying no XSAVE requirement are where this bites, sha and adx
among them, since nothing masks a stale bit once it is read.

Leaf 1 and both leaf 7 subleaves are zeroed when CPUID(0).EAX does not reach
them. Subleaf 1, which the sha512/sm3/sm4 rows read, is additionally gated
on subleaf 0 reporting a max subleaf of at least 1. std_detect gates both the
same way:

https://docs.rs/crate/std_detect/latest/source/src/detect/os/x86.rs

2. Match XSAVE tags to the encodings they gate. None of the
three is an AVX-512 feature. ymm for the VEX-256 forms, none for the
legacy-SSE form of gfni, as with pclmulqdq. gfni needs "" rather than
"ymm": Tremont Atom has GFNI and no AVX at all. sm3 had the opposite error,
"xmm" where its VEX.128 encoding needs ymm; fixed the same way the avx row
was in #1511, leaving no "xmm" rows. Requires the max-basic-leaf
guard above: without it a part whose max basic leaf is below 7 aliases the leaf
7 query, and the relaxed tags no longer mask the aliased bits.

3. Make the guard and the tags unit-testable. Leaf collection moves into
__collect_leaves, parameterized over the CPUID sources. No CI runner reports a
max basic leaf below 7, so the guard is otherwise unreachable in tests.
mod x86 becomes pub mod x86, doc-hidden, since the macro now reaches that
function through $crate::x86:: when expanded downstream; aarch64 and
loongarch64 are already public on the same terms.

4. Require the AVX bit for vaes/vpclmulqdq. The ymm tag checks that the
OS enabled YMM state, not that the CPU reports AVX; fma and avx2 already
conjoin both. sha512 and sm4 are also VEX-encoded and still do not conjoin
it; left alone here, since they were added as a set and are worth their
own change.

5. Make an unknown XSAVE tag a compile error. The tag column was matched at
runtime with a _ => true arm, so a mistyped tag did not fail to build. It
silently removed the state check for that feature. Feature names were already
protected this way; the tag column was not.

vaes/vpclmulqdq no longer imply AVX-512 state. A consumer dispatching an
EVEX-512 form must gate on avx512f separately.

Downstream

aes gates its VAES-256 backend on the bare vaes token, so this changes which
backend it selects on non-AVX-512 parts. That backend batches 30 blocks and does
not override encrypt_tail_blocks, so shorter buffers fall through to cipher's
one-block-at-a-time default.

Aes128::encrypt_blocks, cycles/byte: below 480 bytes VAES-256 runs up to 34%
slower than AES-NI; at and above it, 4 to 5 times faster. The crossover is
exactly the batch width, and the tail cost recurs at every N mod 30 (a
45-block buffer is one full batch plus a 15-block tail, and lands at 1.8x rather
than 5x).

Two limits on those numbers. They were taken on Zen 5, which is not one of
the parts this change affects; it was the x86 hardware I had, and a Gracemont or
Zen 3 result may differ, particularly the size of the win. And they force backend
selection rather than masking CPUID, so they measure the two backends, not the
detection.

The tail path is a pre-existing aes gap. An encrypt_tail_blocks override
there would bound it at parity.

Testing

cargo test -p cpufeatures passes on x86_64-unknown-linux-gnu; on non-x86
targets the module and its tests are cfg'd out. Three of the seven tests fail
against the pre-fix code.

Detection was checked under masked CPUID; no test in this PR produces these.
Rows 1, 3 and 4 are qemu-x86_64 (qemu-user, TCG) with the named -cpu mask;
row 2 is a KVM guest.

configuration	before	after
-cpu Icelake-Server,-avx512f	vaes=false	vaes=true
KVM -cpu Snowridge (GFNI, no AVX)	gfni=false	gfni=true
-cpu Icelake-Server,level=1	vaes=false	vaes=false
-cpu Skylake-Client	vaes=false	vaes=false

The level=1 row is why the guard comes first. Both shipped states are correct
there; a fourth state this PR never produces, relaxation applied with the guard
absent, reports vaes=true on a configuration with no leaf 7 at all.

vpclmulqdq was not measured on any configuration, because QEMU's TCG does not
expose its CPUID bit, and no test covers its tag. Its change rests on the same
encoding argument as vaes.