feat: physical execution for range partitioning (#23231)

## Which issue does this PR close?

- Closes #23137 

## Rationale for this change

Range repartitioning was already planned and serialized into physical
plans, but `RepartitionExec` could not execute it. This PR completes the
core execution path so rows in an input batch are routed to the correct
output partition based on range split points and the ordering defined on
the partitioning scheme.

## What changes are included in this PR?

This PR adds a `Range` variant to `BatchPartitioner` that evaluates the
ordering expressions on each input batch, compares each row's key
against split points using `compare_rows` (respecting ASC/DESC and null
ordering), and assigns row indices to output partitions via binary
search. The partitioned row indices are then materialized into
sub-batches using the same `partition_grouped_take` path as hash
repartitioning. `pull_from_input` is wired to construct a range
partitioner for `Partitioning::Range`, replacing the previous
`not_impl_err!` at execution time.

Optimizer-related paths remain intentionally unimplemented and are
tracked in [#23230](#23230):
projection pushdown through `RepartitionExec`
(`try_swapping_with_projection`), sort pushdown (`try_pushdown_sort`),
and changing partition counts via `repartitioned()`.

## Are these changes tested?

Yes!

## Are there any user-facing changes?

No public API changes

Author: saadtajwar