Select Numpy C API version

[mattiapenati]

This PR introduces the build configuration to select the target Numpy C API version and adjusts struct definitions to match the user selected version.

The default configuration has been chosen to match the setting in the first release of Numpy v2.

The only potentially breaking change is the new definition of PyUFuncObject. The struct PyUFuncObject has been updated to match the definition given in Numpy source. The previous definition matched the definition contained in documentation. I think the former is more accurate.

I understand that this PR is not small and that not all changes can be easily reviewed, it wasn't easy to put everything together either. If the PR is too large, I could split it into smaller changes. Anyway, I hope it will help improve the FFI.

[Icxolu]

Thanks for the PR and for looking into this. As I understand this tries to add version specific condition compilation similar to pyo3 itself, right? rust-numpy currently does this dynamically by reading the API_VERSION at runtime and dispatching based on that. For this reason the struct layouts have to be compatible with all supported versions at all times and we can't include fields introduced in newer versions based on compile time flags. I think the two approaches, at least as currently implemented, at not compatible to each other. I also think that the dynamic approach has the really nice property of leaving the version choice to the consumer. For example I could build an abi3 wheel across a large range of Python versions, some of which only have numpy v1 wheels and others only v2 wheel available. Currently this just works, I think this is a property worth keeping.

Additionally Python¹² (and numpy as well) is slowly moving towards a new stable abi build around opaque PyObjects, so I'm also not sure if it would be wise now to introduce a stronger dependency on PyObject layouts when in the future we probably want to move away from that.

So currently I'm inclined to say we should keep the current design.

cc @davidhewitt @ngoldbaum Maybe you have some opinions/comments for this one as well.

Footnotes

1. https://peps.python.org/pep-0803 ↩

2. https://peps.python.org/pep-0809/ ↩