refactor(parquet): bundle array reader recursion args into ReaderArgs

[HippoBaro]

Which issue does this PR close?

• Spawn off from feat(parquet): selective null padding for list child readers  #9848
• Contributes to Column performance: run-proportional read/write cost #9731

Rationale for this change

The recursive build_reader / build_*_reader methods in the array reader builder thread field and mask through every call.

What changes are included in this PR?

Bundle them into a small Copy ReaderArgs struct so the recursive signatures stay compact and there is a single, documented home for per-field reader options added in the future. This is a mechanical, behavior-preserving change: build_array_reader constructs the args at the entry point, group readers recurse with args.with_field(child), and leaf readers read args.field and args.mask.

Are these changes tested?

All tests passing.

Are there any user-facing changes?

No.

[SoimanVasile]

This is a really clean refactor! I pulled this locally and ran cargo test and clippy against the parquet crate—everything compiles cleanly and all tests pass. Bundling these into ReaderArgs definitely makes the recursive builder thread much easier to read.

I just noticed two minor details while reading through:

1. Consistency Nitpick: In the sub-builder functions (like build_map_reader, build_list_reader), you instantiate a local binding let field = args.field; at the top. However, in the main build_reader function, you match on args.field.field_type directly without the local binding. It might be slightly cleaner to pick one pattern and stick to it uniformly across the file.

2. unwrap() Safety: In build_map_reader (and the list/struct readers), there is:
   let children = field.children().unwrap();
   Even though the Parquet schema invariants should guarantee that map fields have children, since this function already returns a Result, would it be safer to bubble this up as an Arrow schema error instead of panicking if a malformed file somehow slips through?
   (e.g., field.children().ok_or_else(|| arrow_err!("Map field must have children"))?)

   Aside from those minor points, the logic and the with_field implementation look rock solid. Looks good to me.

[alamb]

Thank you @HippoBaro and @SoimanVasile