slowpack OR-accumulates into the output, so a reused buffer kept stale
bits. Zero the target words first.

Introduce a VectorBitPackerKernels interface with a 128-lane
VectorBitPacker128 for Arm NEON and other 128-bit hardware, alongside
the existing 512-bit kernel. A LaneWidth enum selects the encode kernel
from the preferred vector width and tags each stream; decode dispatches
to the tagging width's kernel and fails loud when the host runs only
narrower lanes natively. slowpack/slowunpack move into VectorFastPFOR.

Decode speedup over the scalar FastPFOR codec:
  Graviton2 (Neoverse N1, NEON 128): 2.0-2.9x (~2.7x), encode ~15% faster
  Graviton4 (Neoverse V2, SVE 128): 2.3-4.1x (~3.0x), encode ~8% faster

Add VectorBitPacker256 (AVX2, 256-bit SVE) and register it in the
LaneWidth enum, so 256-bit hosts pack natively instead of stepping down
to the 128-bit kernel.

Decode speedup over the scalar FastPFOR codec:
  Graviton3 (SVE 256): 2.8-4.5x (~3.4x), encode ~13% faster
  AMD EPYC Zen 1 (AVX2 256): 2.4-3.1x (~2.8x), encode ~15% faster

Declare jdk.incubator.vector as requires static so scalar consumers
resolve the module without --add-modules; only VectorFastPFOR users need it.

SkippableBasicTest exercises maxHeadlessCompressedLength, so implement it
(mirroring FastPFOR) rather than throwing.

Hardware-portable Vector API bit-packing for VectorFastPFOR

BinaryPacking using the Vector API pack/unpack kernels: each block is
packed at its own maxbits with no exceptions.

The maxbits computation is vectorized via an OR-reduction over the block.

On Graviton4 (Neoverse V2, SVE2 128-bit), full codec round trip vs
scalar BinaryPacking over 256K random ints: compress 2.5-3.0x faster
across all bit widths; decompress 4.0x at low widths, tapering to
2.4x near width 31.

Add vectorized BinaryPacking int codec