[Jahongir-Qurbonov]

CPython raises IndexError: cannot fit 'int' into an index-sized integer when a list, tuple, str or bytes object is indexed with an int that doesn't fit in Py_ssize_t. Compiled code raised other exceptions:

• OverflowError: Python int too large to convert to C ssize_t from the list, tuple and str item access primitives (get, set and borrowed get).
• ValueError: int too large to convert to i64 from the specialized b[i], ord(s[i]) and s[i] == "x" code (and BytesWriter/StringWriter indexing). A literal index such as b[2**63] was even a compile error.
• The lib-rt primitives also raised OverflowError for ints that fit in Py_ssize_t but aren't short ints (e.g. 2**62), which CPython treats as just out of range ("list index out of range" etc.). list.pop() and list.insert() had the same problem: CPython raises IndexError: pop index out of range and clamps the index, respectively.

The slow paths for non-short int indexes now use PyNumber_AsSsize_t(index, PyExc_IndexError), like CPython. Values that fit fall through to the usual "index out of range" error. The specialized code uses a new slow-path primitive when coercing a non-short int index to i64; the fast path for short ints doesn't change. list.pop() and list.insert() only raise OverflowError when the index doesn't fit in Py_ssize_t, as in CPython.

Slicing and bytearray indexing already matched CPython.

This touches the same run-u64.test lines as #22471 (the OverflowError assertions for tuple/str indexes with large u64 values); I'll resolve the conflict in whichever PR lands second.