GH-3719: Fix vectored read allocation limits and fallback safety (#3726)

## Why are the changes needed?

The Hadoop vectored-read path can fall back to ordinary reads after filesystem
requests have been submitted or results partially consumed. Replaying reads into
the same chunk builder can duplicate selected page data and return incorrect
filtered rows. Outstanding requests also need to retain ownership of their stream
and buffers during failure cleanup.

The current path requests a single buffer for an entire contiguous projected
range, without splitting it at `parquet.read.allocation.size`.

## What changes were proposed in this PR?

- Split requested ranges at the configured allocation size while preserving the
  logical page/column plan. Verify dictionary and V1/V2 page checksums across split
  buffers without another contiguous checksum allocation.
- Cache file length lazily. A non-interruption metadata lookup failure before
  submission disables vectored IO for that reader and permits ordinary reads.
- Fail the read after filesystem submission is attempted, including synchronous
  filesystem rejection; the interface cannot reliably distinguish rejection from
  partial submission.
- Share bounded vectored-read workers across readers: 64 by default, configurable
  once through the JVM system property `parquet.hadoop.vectored.io.threads`.
  Admission, submission, and range waits share one 300-second deadline. Admission
  failure leaves the stream with its reader. Accepted operations retain capacity
  until submission exits, the caller transfers or abandons buffer ownership, and
  failure cleanup finishes. Cancellation cannot free capacity prematurely.
  Idle workers in the default pool expire after 60 seconds.
- Allow engines to supply and share their own pool through
  `withVectoredReadExecutor(new VectoredReadExecutor(executor, maximumConcurrentReads))`
  on read options or the `ParquetReader` builder. Reuse the wrapper to share an
  admission limit across readers; both base and Hadoop options preserve it when
  copied. The shared JVM pool remains the default. Parquet never shuts down a
  caller-owned pool. Reject inline execution before filesystem submission and
  preserve the reader for retry.
- Track original allocator buffers, including merged and checksum allocations,
  and transfer them to the row-group releaser on success. Preserve automatic
  row-group cleanup on sequential reads and reader closure.
- Publish available Hadoop futures even when submission fails. After an operation
  is accepted, invalidate failed readers and defer stream cleanup until submission
  exits; release buffers only when completion can be established. Guarantee abort
  with `finally` even when draining sibling reads throws an `Error`, and retain the
  original failure as suppressed on the escaping error. Remove the unused CRC allocator.

The allocation setting bounds requested range lengths, not every filesystem
allocation: backends may merge ranges or align them for checksums and allocate
larger buffers. It does not bound footer/decoder allocations or total memory.
The worker limit does not bound threads created by the filesystem. A backend
that ignores interruption, or a blocked stream close, can retain capacity
indefinitely; when all workers are occupied, further reads time out at admission.
Missing, cancelled, or never-completing result futures can prevent safe buffer
reclamation. Caller-supplied executors must dispatch asynchronously, reject instead
of silently dropping work, and drain accepted tasks during shutdown. Reading
threads must not exhaust that same pool while waiting for their vectored work.

## How was this PR tested?

Local validation used Java 17.0.20.1 with Maven 3.9.16 and Thrift 0.24.0:

- Full `parquet-hadoop` verification with default Hadoop 3.3.0: **877 tests,
  zero failures/errors, 26 Hadoop-capability skips**, plus **17 integration tests
  with zero failures/errors/skips**. Packaging, API compatibility, dependency
  analysis, Spotless, and RAT (274 approved licenses) passed.
- Focused Hadoop 3.4.1 run with `-Dparquet.hadoop.vectored.io.threads=2`:
  **118 tests, zero failures/errors/skips**, including the real local-filesystem
  vectored and file-range bridge tests.
- `git diff --check` passed.

The focused run selected
`TestParquetFileReaderVectoredIO,TestParquetFileReaderVectoredOwnership,TestVectoredReadBufferAllocator,TestVectoredReadOperation,TestVectoredReadExecutor,TestDataPageChecksums,TestVectorIoBridge,TestFileRangeBridge,TestParquetFileReaderBufferLeak`.

Coverage includes shared admission across repeated retries, capacity retained
through blocked submission and cleanup, original-buffer ownership, interrupted
admission and reader reuse, queued aborts, and sibling errors with pending reads.
New regressions exercise caller-owned pools through both options builders and
copies, successful reads and error cleanup without pool shutdown, inline and
`CallerRunsPolicy` rejection, permit recovery, and retrying the same reader after
inline rejection.

The full unit suite used a RAM-backed temporary directory for its large-file tests.
Local setup also used a test-JVM hosts file for the machine hostname and interop
fixtures fetched at the commits pinned in the tests. No live S3 validation or
performance benchmark was performed.

GitHub CI for head `effbc384` also passed:

- Hadoop JDK 17 verification ran on merge revision `ad7b9934`, which includes this
  head: **898 `parquet-hadoop` tests, zero failures/errors, 26 skips**. With default
  Hadoop 3.3.0, all 22 `TestVectorIoBridge` tests were skipped; real local-filesystem
  bridge coverage comes from the separate Hadoop 3.4.1 run above.
- Vector-plugin verification on JDK 17, 21, and 25, and zizmor analysis passed.

Closes #3719.