add numpy 2 support

[MuellerSeb]

Closes: #337 #345

Numpy 2.0.0rc1 was released: https://pypi.org/project/numpy/2.0.0c1 and is officially usable to build extensions.

• numpy 2.0.0rc1 for building extensions (for Python 3.9 and above)
• check multiple numpy and scipy versions in CI
• fixed minimal versions for numpy
• use np.asarray everywhere with np.atleast_(n)d
• fix long/longlong integer issue in cython on windows by always using 64bit integers

Additional doc fixes

• build docs with latest sphinx version
• require pyvista 0.40 at least

32bit builds were removed with this PR. I think we can happily drop that.

[MuellerSeb]

• Building with numpy 2 works 🎉
• Running tests with numpy 2 fails 😭

A lot of the tests fail because of emcee and this issue: dfm/emcee#509

Other errors have a problem with these lines in estimator.pyx:

    cdef long[:, :] counts = np.zeros((d_max, len(bin_edges)-1), dtype=long)
    cdef long[:] counts = np.zeros(len(bin_edges)-1, dtype=long)
    cdef long[:] counts = np.zeros(k_max, dtype=long)
    cdef long[:] counts = np.zeros(k_max, dtype=long)

and raise

E   ValueError: Buffer dtype mismatch, expected 'long' but got 'long long'

This only occurs on windows and is related to this: https://numpy.org/devdocs/numpy_2_0_migration_guide.html#windows-default-integer

One other category of errors is:

If using `np.array(obj, copy=False)` replace it with `np.asarray(obj)` to allow a copy when needed (no behavior change in NumPy 1.x).

np.array(..., copy=False) is used in krige/base.py, 3 times in variogram/variogram.py and 3 times in tools/geometric.py

In order to mimic the ndmin=... feature, we could replace these with e.g.:

pos = np.atleast_2d(np.asarray(pos, dtype=np.double))

[MuellerSeb]

All issues fixed. Only remaining issues should be solved upstream in emcee with: dfm/emcee#510

[LSchueler]

Awesome, thanks for this! I guess the most annoying work was the CI stuff?

I have just added a few questions / comments to the code.

[LSchueler]

This is awful! But I guess there is no other way until py 3.11 is deprecated?

[MuellerSeb]

What exactly is awful? I think it is pretty neat to test multiple numpy/scipy versions to fix stuff like #246 faster in the future.

[LSchueler]

It's just a lot of manual (and typo prone?) work. Just imagine we have to add another few packages to that version matrix.

And it also makes it more work to locally reproduce specific setups of users.

[MuellerSeb]

If a new Python version is release we have to add it by hand either way. And then I would just add the first version of numpy and scipy that support that new python version. That is how I selected the numpy and scipy versions for the python version together with a bleeding edge job for the latest versions.

[MuellerSeb]

I would like to keep it like this for now. If we encounter version incompatibilities in the future, we can rethink this.

[LSchueler]

It'd be funny to see the number of changed files across open source Python projects after changes in the black formats :-)

LGTM!