Fixes mypyc/mypyc#1227

This is just an idea for how to improve performance, for an issue that
was exposed to me because of the issues in PR #22097 .

`isinstance(x, (A, B))` is specialized when every class in the tuple is
a primitive type (#19949) or every class is a native class
(mypyc/mypyc#413). Anything else falls back to the generic path, which
builds a new tuple and calls `PyObject_IsInstance` on every call, so the
primitive types in the tuple lose their fast checks as well. That
covers:

- a primitive type mixed with a native class: `isinstance(x, (float,
MyNativeClass))`
- a primitive type mixed with any other class: `isinstance(x, (float,
Decimal))`
- nested tuples, even when every class is a primitive type:
`isinstance(x, (int, (float, str)))`

The chained checks added in #19949 could be generalized:
flatten nested tuples, use the fast checks for primitive types and
native classes, and check any other class with its own
`PyObject_IsInstance` call, so no tuple is built. In a quick
microbenchmark this takes `isinstance(x, (float, MyNativeClass))` from
about 50 ns to about 5 ns per call.

Relatedly, `isinstance(f(), ())` currently returns `False` without
calling `f()`.

Fixes mypyc/mypyc#1228

This is a duplicate of #22099. I'm opening this due to Github issues
yesterday. This includes patches due to @p-sawicki's review

Reading `.real` or `.imag` from a value typed as `int`, `float`,
`complex`, or a union of them was compiled to a generic attribute
lookup, whose result was then unboxed or type-checked again. Native
`int`, `bool` and `float` values were even boxed first, only to read
back the same value or zero. I ran into this in the same code as #22097.

This specializes these reads when the static type of the receiver is
`int`, `float`, `complex` or a union of them, which includes values
narrowed by `isinstance()`:

- On native `int`, `bool` and `float` values, `x.real` is the value
itself (converted to an `int` for a `bool`), and `x.imag` is `0` or
`0.0`.
- When the result is a `float` (receivers typed `float`, `complex` or
`float | complex`), new `CPyComplex_Real` and `CPyComplex_Imag`
primitives read exact `complex`, `float` and `int` objects directly as a
C double.
- When the result can be an `int` (receivers such as `int | float |
complex`), new `CPyNumber_Real` and `CPyNumber_Imag` primitives return
exact `int` and `float` objects themselves, as `int.real` and
`float.real` do, and read exact `complex` objects directly.

Anything else (a subclass that overrides `real` or `imag`, a `bool` in a
union, or an object of the wrong type at runtime) uses the same lookup
as before, followed by the same unboxing or type check, so results and
error messages don't change.

The run tests cover NaN, infinities, `-0.0`, a value equal to mypyc's
float error value (`-113.0`), small and large ints, bools, subclasses
that override the properties, and the error cases.

Microbenchmark results (Python 3.12, ns per value):
- `z.real + z.imag` with `z: complex`: 59.3 -> 6.0
- the same with ints passed as `z: complex`: 55.8 -> 7.1
- `x.real + x.imag` with `x: float`: 49.9 -> 6.0
- `x.real + x.imag` with `x: int`: 41.8 -> 9.9
- `x.real` and `x.imag` with `x: int | float | complex`: 29.6 -> 8.1
with ints, 36.9 -> 13.0 with floats, 46.3 -> 18.8 with complex values
(35.0 -> 25.7 when the three alternate)
- `if isinstance(x, (float, complex)): real, imag = x.real, x.imag` with
`x: Any`: 93.9 -> 52.7, or 6.6 together with #22097