Support for newer API version

[mattiapenati]

The current implementation is targeting the ABI v2 and the API v1.15. This choice ensures a wide compatibility of the extensions built using this crate. As already discussed in #534 it can be useful for extension's developers to choose the target API version, in order to make the newer features of NumPy available.

I try to summarize the previous discussion:

• It's fine to target only the ABI v2.
• It can be helpful for extensions' developers to make the choice of the target API version in an explicit way. With runtime checks it's hard to define a good NumPy minimum version.
• Features are not usable because of their additive design and because NumPy does not use semantic versioning.

It seems that an easy solution to provide API selection is not feasible, both at runtime and compile time. The usage of mutually exclusive features was not discussed, I think it is a viable solution and it is hard for me to think of an other solution. I know that it is not without drawbacks, in particular a compilation error arises if multiple incompatible features are enabled in the dependency graph, but how common is this situation?

I'm going to cite all the users that have participated in the previous discussion. I hope you are already interested in this topic, if not, I apologize for the noise. @Icxolu @ngoldbaum @seberg

[Icxolu]

Thank you for continuing to push this.

I recently wondered if we could make use of cargo's metadata table together with extending our build script to make API selection possible via cfgs like PyO3.

Something like this:

# Cargo.toml
# ...

[package.metadata.numpy]
api = "1.18"

which would then enable the flags NPY_1_15, NPY_1_16, NPY_1_17, NPY_1_18.
We could set a sane default for when no metadata is present and let users explicitly overwrite it with it if needed.