GH-51268: [C++][Parquet] Scan DELTA_BINARY_PACKED deltas a vector at a time - #51295

...ne call
The miniblocks of a DELTA_BINARY_PACKED block are packed back to back
with no padding between them, so a run of miniblocks that share a bit
width is bit-identical to a single longer run at that width. GetInternal
called the bit unpacker once per miniblock all the same, which with the
default geometry is one call per 32 values - mostly per-call setup.
Look ahead over the block's stored bit widths and extend the current
call over each following miniblock that has the same width and that the
caller has room for in full. A miniblock joins the run only when its
width equals the current delta_bit_width_, which InitMiniBlock has
already validated, and the run also stops at the end of the block. Add a
test over the width patterns that decide where a run starts and stops,
and read at a batch size that stops partway through a coalesced run.
On the decode benchmarks already in the tree this is 1.17x to 1.33x on
top of the previous commit wherever the unpacker's per-call cost is a
meaningful share of the work. Decoded values are identical; no encoded
byte changes.

The two non-degenerate DELTA_BINARY_PACKED decode arms both hold values
in random order, so their deltas are random and the frame sits well
below zero. The columns this encoding is chosen for are usually
non-decreasing, where every delta is non-negative instead and the frame
is at or near zero.
Add an arm whose deltas come from the same 1000-wide range as the
existing narrow one but accumulate, so the two differ in the order of
the values at a nearly unchanged packed width.

The prefix sum that turns deltas back into values does one addition per
value, and each one waits on the value before it, so the loop is bound
by that chain rather than by how much arithmetic the machine can retire.
Replace it with an inclusive scan, which shifts and adds a vector to
itself once per power of two and so turns a vector of deltas into a
vector of running sums. That shortens the chain from one addition per
value to one per vector. The frame is added before the scan, which makes
its running multiple fall out of the scan itself, and the previous
vector's last value is carried forward in a vector register -- reading
it out into a general-purpose register instead costs several times what
the scan saves. The scan runs only where a register holds at least four
values, the narrowest width measured to win; below that, and on the
tail, the value-at-a-time loop does the work. xsimd is already a
dependency of this target, so nothing is added to the build.
Decode throughput over the previous commit, on the arms whose values are
32-bit: 1.26x on non-decreasing values, 1.24x in random order, and 1.23x
at 31 bits per delta. The 64-bit arms hold two values in a register here
and are unchanged. Together with the two commits before it this is
2.17x, 2.11x and 1.89x over main, or 2.64 to 5.73 GB/s of decoded output
on non-decreasing values.