parquet: return an error instead of panicking when a pushed buffer's length does not match its range

[ranflarion]

Which issue does this PR close?

Closes #10563.

Rationale for this change

A short read pushed into the parquet push decoder panics at PushBuffers::push_range ("Range length must match buffer length") although every public entry point that feeds it returns Result. Through the async reader this turns a transient store fault into a reader-thread panic the caller cannot classify or retry; the json and avro readers surface the equivalent fault as a decode error.

What changes are included in this PR?

PushBuffers::push_range and push_ranges return Result<(), ParquetError> instead of asserting (buffer/range length mismatch, and ranges/buffers count mismatch in push_ranges). The error propagates through the crate-internal chain: ParquetMetaDataPushDecoder::push_range/push_ranges (already Result, now use ?), and ParquetDecoderState::push_data -> RemainingRowGroups::push_data -> RowGroupReaderBuilder::push_data, the last two becoming fallible; all their callers were already in Result contexts.

Are these changes tested?

New unit tests in push_buffers.rs cover the accepted case, the short-buffer error, and the count-mismatch error. The existing parquet test suite passes.

Are there any user-facing changes?

Changes to PushBuffers public API; push_range() and push_ranges() now return a Result<(), ParquetError>. Code that previously panicked on mismatched pushes now receives an Err.

[Jefffrey]

marking as api change since PushBuffers is part of public api via push decoder export:

arrow-rs/parquet/src/arrow/push_decoder/mod.rs

Line 30 in 6b7d6b3

pub use crate::util::push_buffers::PushBuffers;

see: https://docs.rs/parquet/latest/parquet/arrow/push_decoder/struct.PushBuffers.html

[alamb]

Thank you @ranflarion and @Jefffrey