[Python] Convert to_pylist fast paths per range instead of per element

[viirya]

Describe the enhancement requested

Follow-up of #50326 (mechanism introduced in GH-50327). The scalar-free conversion currently makes one _getitem_py virtual call per element. Several per-element overheads could be batched per range, as suggested in the GH-50327 review:

1. Replace the per-element entry point with a cdef list _getitem_range_py(self, int64_t offset, int64_t length) used by to_pylist and the list/struct/map container loops, cutting per-element function-call and prologue overhead.
2. Hoist the numeric type-id dispatch out of the loop: NumericArray._getitem_py currently walks an if/elif ladder per element even though the type is invariant; a per-range implementation (or per-concrete-class overrides) makes the loop monomorphic.
3. Skip the per-element IsNull check when null_count() == 0.
4. Read the offsets buffer pointer once per range in the list/map paths instead of calling value_offset() twice per row.

None of these change semantics; they compound on top of the structural win in GH-50327 (no per-element Scalar / per-row Array wrapper allocation).

Component(s)

Python

[pitrou]

Note that we could refactor and reuse the C++ ObjectWriterVisitor that exists in pyarrow/src/arrow/python/arrow_to_pandas.cc. This would reduce code duplication and bring support for non-trivial types such as timestamps etc.

[viirya]

Planning note: I'll pick this up after #50430 (the maps_as_pydicts fast path) is resolved — it rewrites the same _getitem_py loop structure and threads a parameter through every specialization, so sequencing the two avoids churning the same code under review. First step will be a prototype to measure the actual headroom (the numeric paths are already at ~7ns/element, close to ndarray.tolist, so the expected gains are mainly in the string/list paths from hoisting the per-child dispatch out of the loop).