Optimize DocValues using Panama API decoders for Byte Short and Int to Long instead of default scalar loop

[CH-Abhinav]

Description

This PR is adding Panama Vector API decoders into PanamaDocValuesBulkDecodeSupport.java instead of using default scalar decoders. In this PR aim is to get optimized decoders for Byte Shortand Int to Long versions like how decoder for Long to Long already exists. Closes #16451 .

Analysis

Using single LongVector to calculate shapeconvert() is sub-optimal due to memory fetch bottlenecks. And standard JIT C2 compiler isn't auto-verctorzing scalar loops to reach Panama Vector's performance due to shape mismatches.

so this PR introduces decode8 (Byte to Long), decode16 (Short to Long) and decode32 (Int to Long). To maximize memory bandwidth while strictly avoiding L1 cache register spilling on AVX2 hardware (16-register limit), the loops are explicitly unrolled:

decode8 (Byte to Long) & decode16 (Short to Long): Locked to a 4x expansion ratio (1 input vector unrolled to 4 LongVector outputs). Limits active YMM registers to 5.

decode32 (Int to Long): Locked to a 2x expansion ratio (1 input vector unrolled to 2 LongVector outputs). Limits active YMM registers to 3.

Benchmark

The JMH benchmarks were executed on JDK 25.0.3

Benchmark	Count	Scalar Baseline	Panama (4 Vectors)	Panama (8 Vectors)	Units
DocValues Decode (8-bit)	1,024	2.859 ± 0.767	4.470 ± 0.670	2.462 ± 0.414	ops/us
DocValues Decode (8-bit)	65,536	0.039 ± 0.003	0.049 ± 0.010	0.041 ± 0.010	ops/us

(Note: We tested 8 vectors to find the register spill threshold, which collapses performance below the scalar baseline as shown above. Additionally, on GraalVM, the JIT compiler auto-vectorizes the scalar loops effectively enough to match this manual vectorization).

Testing

added a test TestDocValuesBulkDecodeSupport.java to test the decoders in PanamaDocValuesBulkDecodeSupport.java.

[CH-Abhinav]

Any maintainer out there who can approve github actions ?