[Jahongir-Qurbonov]

This fixes three related bugs in int/float primitives.

1. Crashes with large int subclass values. When an int value doesn't fit in a short int, unboxing keeps the original object, so a long tagged int can be an instance of an int subclass. The slow paths of int operations used PyNumber_* / PyObject_RichCompareBool, which call dunders the subclass overrides:

# sub.py (not compiled)
class Str(int):
    def __sub__(self, o): return 1.5
    def __eq__(self, o): raise RuntimeError()

# compiled
def sub(a: int, b: int) -> int: return a - b
def eq(a: int, b: int) -> bool: return a == b

sub(Str(2**70), 2**70)  # segfault (float read as an int object)
eq(Str(2**70), 2**70)   # "fatal: out of memory", process aborts

Small values never call the overrides. The slow paths now first convert operands to exact ints using int's own nb_int slot, so no overrides are called. Normalizing at unboxing time isn't possible, because wrapper functions and attribute setters borrow the argument. CPyTagged_TrueDivide now also checks for errors from PyFloat_AsDouble.

2. int / int was not correctly rounded for operands larger than 2**53. For example, (2**53 + 1) / 3 gave 3002399751580330.5 instead of 3002399751580331.0. The double fast path is now only used if both operands fit in 53 bits, as in CPython.

3. float vs int comparisons converted the int to a float. 2.0**53 == 2**53 + 1 was True, and 1.0 < 2**1100 raised OverflowError. Comparisons now use a new CPyFloat_CompareTagged primitive. It compares as doubles only if the int fits in 53 bits; otherwise it falls back to a rich comparison. Int literals are still converted at compile time when the conversion is exact. Arithmetic is unchanged.

Added run tests for all three, and irbuild tests for the comparisons.