Optimize Parquet lazy repdef window decode

[Gin-Fung]

Summary

This PR optimizes Parquet repetition/definition level decoding by adding a lazy windowed decode path.

The change is split into three logical commits:

1. Add option plumbing for Parquet repdef preload window mode.
2. Add the preload window implementation.
3. Optimize the hot path by avoiding extra leaf-count decode work and repeated top-level row boundary scans.

Validation

Validated locally with:

• bolt_dwio_parquet_reader_test
• bolt_dwio_parquet_table_scan_test
• bolt_dwio_parquet_cli_test

Both default mode and window preload mode passed.

[CLAassistant]

All committers have signed the CLA.

[liuneng1994]

This changes the core rep/def preload/decode path, but I don't see any tests added in this PR. Can we add coverage for window mode vs the existing path on nested repeated/optional data? The cases I would expect at minimum are: window mode disabled, window mode enabled across multiple pages, and skip/seek after only part of the window has been decoded.

[liuneng1994]

This looks like a second implementation of Parquet def-level RLE decoding. Can we reuse the existing level decoder path, or extract a shared helper, instead of hand-parsing the RLE runs here?
This is a correctness-sensitive format detail and easy to drift from the normal path.

[liuneng1994]

This duplicates the leaf-null compaction logic, including the glibc/FSRM memcpy workaround from the existing path. Can we extract that existing block into a shared helper and call it from both
paths?

[liuneng1994]

These window-mode fields are tightly coupled. Can we group them into a small private state struct, maybe with a reset() method? That would make the invariants easier to follow.

[liuneng1994]

The optimization direction looks reasonable, but I think this PR needs more work before it is easy to review and maintain.

A few concerns:

1. Please add checked-in tests for the new windowed rep/def path. Local validation is not enough for this kind of reader state-machine change. We should cover at least: window mode disabled,
   window mode enabled across multiple pages, repeated calls to decodeRepDefs(), and skip/seek after only part of the window has been decoded.

2. Please add a focused microbenchmark for this optimization. Since this is a performance change, we need benchmark numbers that isolate the new windowed decode path and compare it with the
   existing preload path on representative nested/repeated data.

3. Some of the new code looks like it is re-implementing existing low-level logic. For example, countLeavesInRepDefPage() hand-parses def-level RLE, and compactConsumedLeafNulls()
   duplicates the existing null compaction logic including the memcpy workaround. Can we reuse the existing level decoding / null compaction path, or extract shared helpers instead of duplicating
   this logic?

4. The readability could be improved by grouping the new window-mode state. The new window* fields in PageReader are tightly coupled and have reset/compact invariants. A small private
   WindowRepDefState struct with a reset() method would make the state transitions easier to follow.

5. I would avoid reading BOLT_PARQUET_REPDEF_PRELOAD_WINDOW_COUNT directly inside PageReader. Since the PR already adds RowReaderOptions::setParquetRepDefPreloadWindowCount(), it is
   cleaner to keep this as explicit option/config plumbing rather than a process-wide env var side channel.

Overall, I think the PR should aim for: enough reuse with the existing rep/def decode machinery, tests for the new behavior, and a microbenchmark showing the performance win.