GH-51268: [C++][Parquet] Unpack equal-width DELTA_BINARY_PACKED miniblocks in one call - #51250

Rationale for this change

The miniblocks of a DELTA_BINARY_PACKED block are packed back to back with no padding, so
consecutive miniblocks that share a bit width are bit-identical to one longer run at that
width. The decoder calls the bit unpacker once per miniblock all the same -- at the default
geometry one call per 32 values, which at narrow widths is mostly per-call setup.

What changes are included in this PR?

A look-ahead over the block's stored bit widths reports how many following miniblocks can be
folded into the current unpack call, so a run of four asks for 128 values instead of 32. A
miniblock joins the run only when its stored width equals the current one, which has already
been validated, so coalescing never depends on an unchecked width. The run also stops at the
end of the block and at what the caller has room for.

A zero bit width needs no unpack call, so the caller tests for it before the look-ahead.
That reads redundant, since the look-ahead declines anyway, but is not free to drop: without
it the two zero-width arms lose 17%. Both builds emit the same loops with the same
instruction counts, so this is how the compiler arranges the function rather than work saved
-- but it reproduces well outside build-to-build spread.

Are these changes tested?

A new typed test covers the width patterns that decide where a run starts and stops, and the
fixture gains a read batch size that stops partway through a coalesced run. Three mutations
-- ignoring the neighbour's width, ignoring the caller's room, and failing to advance the
block cursor -- each turn it red on both integer widths.

Benchmark

Graviton4, GCC 11.5, Release, one core, 9 repetitions, medians, 65,536 values. Both points
built twice with the builds interleaved; the two builds agree within 0.6%.

The Fixed arms are the zero bit width path: they gain nothing here and give up 2-3% for
the check that keeps them out, stable across builds rather than noise. The wide arms gain
least, spending their time inside the unpacker rather than around it.

Are there any user-facing changes?

No. No API change, no format change, and decoded values are identical.

• GitHub Issue: [C++][Parquet] Speed up DELTA_BINARY_PACKED decoding #51268