GeezerVison

Unboxing an int keeps the original object when the value doesn't fit in
a short int, so a long tagged int can refer to an instance of an int
subclass. The slow paths of int operations used the generic PyNumber_*
and rich comparison APIs, which call any dunder methods the subclass
overrides. A non-int result was then read as an int object (crash or
garbage), and an exception in an operation that can't fail aborted the
process with "fatal: out of memory".

Convert operands to exact int objects in the slow paths, using int's own
nb_int slot so that no overrides are called. This matches the behavior
for small values, which never call the overrides. Also check for errors
from PyFloat_AsDouble in CPyTagged_TrueDivide.

The fast path of int true division converted short int operands to
doubles before dividing, which rounds twice if an operand can't be
represented exactly as a double. For example, (2**53 + 1) / 3 returned
3002399751580330.5 instead of 3002399751580331.0.

Only use the fast path if the absolute values of both operands are at
most 2**53 (like CPython), and otherwise fall back to the int object
implementation, which is correctly rounded.

Comparisons between float and int converted the int to a double first,
which loses precision for ints with an absolute value larger than 2**53
and raises OverflowError for very large ints. For example,
2.0**53 == 2**53 + 1 was True, and 1.0 < 2**1100 raised OverflowError.
CPython compares the values exactly.

Use a new primitive CPyFloat_CompareTagged for these comparisons. It
compares as doubles if the int is a short int that fits in 53 bits, and
otherwise falls back to a rich comparison of the boxed values. Int
literals are still converted to float at compile time if the conversion
is exact. Arithmetic operations are unchanged.

Int literals such as 2**53 don't fit in a short int on 32-bit platforms, so the generated IR is different.