Introduced in e593b0ac due to a bug when inputs had zero-strides.

The bug can be fixed just by removing a block that assumed some `full`/`broadcasting` behavior by the operation, but this is not happening with DimShuffle.

This was caused by 223ee154, which used the generic `PyArray_IntpConverter` to convert the shape numpy vector into a simple C-array for the Reshape operation. There seems to be no need for this change as the strides were correctly used

Profiling suggests the previous changes caused a 7.5x slowdown. The benchmark detects only a 2.3x slowdown due to the PyTensor call overhead.

* Added print_shape option to debugprint and simplify __str__ logic in TensorType
* Add print_memory_map option to debugprint to enable destroy and view maps

For more context, see the discussion in:
https://github.com/conda-forge/pytensor-suite-feedstock/pull/133#issuecomment-2673831166

* Fix bug in solve_triangular when `overwrite_b = True`

* Add regression test

pytest-sphinx is not compatible with Python 3.13: https://github.com/twmr/pytest-sphinx/issues/67

We want to test numpy 1.26.x on `test_math.py` but test_math.py was being excluded in python 3.10, and numpy 1.26.x was being excluded in the non python3.10 job.

<https://conda-forge.org/news/2024/08/14/sunsetting-pypy/>

Notably changes the behavior of `__bool__` to always raise. Before there was a hack based on whether a variable had been compared to something before.

Co-authored-by: Adv <adhvaithhundi.221ds003@nitk.edu.in>

Remaining tests now run on latest numpy,
except for Numba jobs, which need numpy 2.1.0

Also added ruff numpy2 transition rule.

I split this test up to test uint64 separately, since
this is the case discussed in Issue #770. I also added
a test for the exact example used in that issue.

The uint dtypes with lower precision should pass.

The uint64 case started passing for me locally on Mac OSX,
but still fails on CI. I'm not sure why this is, but at
least the test will be more specific now if it fails in the future.

Due to changes in numpy conversion rules (NEP 50),
overflows are not ignored; in particular, negating
a unsigned int causes an overflow error.

The test for `neg` has been changed to check that
this error is raised.

In numpy 2.0, if axis=None, then np.unique
does not flatten the inverse indices returned
if return_inverse=True

A helper function has been added to npy_2_compat.py
to mimic the output of `np.unique` from version of
numpy before 2.0

From numpy PR https://github.com/numpy/numpy/pull/22449,
the repr of scalar values has changed, e.g. from "1" to
"np.int64(1)", which caused two doctests to fail.

I was getting a NameError from the list
comprehensions saying that e.g. `pytensor_scalar`
was not defined. I'm not sure why, but this is another
(more verbose) way to do the same thing.

1. Changed autocaster due to new promotion rules

With "weak promotion" of python types in Numpy 2.0,
the statement `1.1 == np.asarray(1.1).astype('float32')` is True,
whereas in Numpy 1.26, it was false.

However, in numpy 1.26, `1.1 == np.asarray([1.1]).astype('float32')`
was true, so the scalar behavior and array behavior are the same
in Numpy 2.0, while they were different in numpy 1.26.

Essentially, in Numpy 2.0, if python floats are used in operations
with numpy floats or arrays, then the type of the numpy object will
be used (i.e. the python value will be treated as the type of the numpy
objects).

To preserve the behavior of `NumpyAutocaster` from numpy <= 1.26, I've
added an explicit conversion of the value to be converted to a numpy
type using `np.asarray` during the check that decides what dtype to
cast to.

2. Updates due to new numpy conversion rules for out-of-bounds python
ints

In numpy 2.0, out of bounds python ints will not be automatically
converted, and will raise an `OverflowError` instead.
For instance, converting 255 to int8 will raise an error, instead of
returning -1.

To explicitly force conversion, we must use
`np.asarray(value).astype(dtype)`, rather than
`np.asarray(value, dtype=dtype)`.

The code in `TensorType.filter` has been changed to the new recommended
way to downcast, and the error type caught by some tests has been
changed to OverflowError from TypeError

In numpy 2.0, -1 as uint8 is out of bounds, whereas
previously it would be converted to 255.

This affected the test helper function `reduced_bitwise_and`.
The helper function was changed to use 255 instead of -1 if
the dtype was uint8, since this is what is needed to match the
behavior of the "bitwise and" op.

`reduced_bitwise_and` was only used by `TestCAReduce`
in `tests/tensor/test_elemwise.py`, so it was moved
there from `tests/tensor/test_math.py`

`np.MAXDIMS` was removed from the public API and
no replacement is given in the migration docs.

In numpy <= 1.26, the value of `np.MAXDIMS` was 32.
This was often used as a flag to mean `axis=None`.

In numpy >= 2.0, the maximum number of dims of an
array has been increased to 64; simultaneously, a
constant `NPY_RAVEL_AXIS` was added to the C-API to
indicate that `axis=None`.

In most cases, the use of `np.MAXDIMS` to
check for `axis=None` can be replaced by the
new constant `NPY_RAVEL_AXIS`.

To make this constant accessible when using numpy <= 1.26,
I added a function to insert `npy_2_compat.h` into the support
code for the affected ops.

numpy.random.Generator.__getstate__()
now returns none; to see the state of
the bit generator, you need to use
Generator.bit_generator.state.

This change affects `RandomGeneratorType`, and
several of the random tests (including some for Jax.)

This was done for the python linker and numba linker.

deepcopy seems to be the recommended method for
copying a numpy Generator.

After this numpy PR:
https://github.com/numpy/numpy/pull/26293/commits/44ba7ca07984557f2006f9a6916adb8e3ecfca61
`copy` didn't seem to actually make an independent copy of
the `np.random.Generator` objects spawned by `RandomStream`.

This was causing the "test values" computed by e.g.
`RandomStream.uniform` to increment the RNG state, which
was causing tests that rely on `RandomStream` to fail.

Here is some related discussion:
https://github.com/numpy/numpy/issues/24086

I didn't see any official documentation about
a change in numpy that would make copy stop
working.

MapIter was removed from the public numpy C-API in
version 2.0, so we raise a not implemented error to
default to the python code for the AdvancedInSubtensor1.

The python version, defined in `AdvancedInSubtensor1.perform`
calls `np.add.at`, which uses `MapIter` behind the scenes.
There is active development on Numpy to improve the efficiency
of `np.add.at`.

To skip the C implementation and use the Python implementation,
we raise a NotImplementedError for this op's c code if numpy>=2.0.

This is done using C++ generic functions
to get/set the real/imag parts of complex numbers.

This gives us an easy way to support Numpy v < 2.0,
and allows the type underlying the bit width types,
like pytensor_complex128, to be correctly inferred
from the numpy complex types they inherit from.

Updated pytensor_complex struct to use get/set real/imag
aliases defined above. Also updated operators such as
`Abs` to use get_real, get_imag.

Macros have been added to ensure compatibility with numpy < 2.0

Note: redefining the complex arithmetic here means that we
aren't treating NaNs and infinities as carefully as the C99
standard suggets (see Appendix G of the standard).

The code has been like this since it was added to Theano,
so we're keeping the existing behavior.

Anything `Hashable` should work, but I've made the
return type `tuple[Hashable]` to keep with the current style.

This means, e.g., we can use strings in the cache version.

- replace `->elsize` by `PyArray_ITEMSIZE`
- don't use deprecated PyArray_MoveInto