GH-51145: [Python] Accept Arrow integer scalars in slice methods

[YusefSyed]

Rationale for this change

Array.slice, ChunkedArray.slice, RecordBatch.slice, and Table.slice
accept Python and NumPy integer-like values but reject Arrow integer scalars,
even though those scalars implement Python's integer-index protocol. This makes
values produced by Arrow APIs unnecessarily unusable as slice offsets and
lengths.

What changes are included in this PR?

Normalize non-None offsets and lengths with operator.index() at the four
public Python wrapper boundaries before the existing validation and C++ calls.

Add regression coverage for all signed and unsigned Arrow integer scalar types
across the four wrappers, plus NumPy compatibility, invalid and null scalars,
negative values, offset clamping, and int64 overflow behavior.

Are these changes tested?

Yes. Current Arrow C++ and editable PyArrow were built from source in an
isolated Python 3.13 environment. The focused new tests and existing slice
controls passed: 48 passed.

Cython translation, Python test-file compilation, Flake8, and
git diff --check also passed.

Are there any user-facing changes?

Yes. The four Python .slice() methods now accept non-null Arrow integer
scalars for offsets and lengths. Existing Python/NumPy integer behavior and
error behavior for unsupported values are preserved.

AI assistance

AI assisted analysis, implementation, test drafting, build work, and review.
The account holder reviewed and approved the final four-file diff. The account
holder did not personally run the commands reported above.

• GitHub Issue: [Python] .slice methods should accept Arrow scalar types #51145

[AlenkaF]

Thanks for the PR! I was thinking of suggesting the use of Py_ssize_t-typed Cython parameter but operator.index() does solve everything: accepts Python ints and Arrow Scalars if they are integer type. cc @raulcd what do you think?

In any case, we need to update docstrings for offset and length as they do not need to be int but can also be Arrow Scalars.