Update to target ABI v2

[mattiapenati]

This PR contains the implementation discussed in #534. The npyffi module has been updated to match the NumPy implementation of ABI v2 when the NPY_FEATURE_VERSION macro is set to 0x0000000c (v1.15). Some new macros are required for the implementation, I prefer to follow the same layout of NumPy to make easier future changes.

The major changes of this PR are:

• NonNull marker is used to store the pointer contained in capsules.
• Multiarray and UFunc APIs have been updated to match the NumPy public API.
• A consistent way to define opaque data types is used, T([u8; 0]).
• Types related to npy_longdouble have been commented; previously they were related to f64, but on some platforms long double is 80-bit extended precision.
• The runtime compatibility is now checked when the NumPy API is initialized and this check has been ported from NumPy.

During the implementation, some doubts arose:

• Why is std::os::raw used? Usually std::ffi is preferred.
• Why are all the type definitions related to functions wrapped in Option<...>? I found that the usage of Option<...> is more common in member definitions, probably even in pyo3. For example:

  type Callback = extern "C" fn (*mut c_void) -> *mut c_void;
  #[repr(C)]
  struct Operator {
    data: *mut c_void,
    callback: Option<Callback>,
  }
  // in place of
  type Callback = Option<extern "C" fn (*mut c_void) -> *mut c_void>;
  #[repr(C)]
  struct Operator {
    data: *mut c_void,
    callback: Callback,
  }

[Icxolu]

Not a full review, will try to give this a read tomorrow.

• Why is std::os::raw used? Usually std::ffi is preferred.

Most likely a left over from the times before std::ffi was stabilized on MSRV. 👍 to changing that.

• Why are all the type definitions related to functions wrapped in Option<...>? I found that the usage of Option<...> is more common in member definitions, probably even in pyo3

Good question, not sure. I think I'd also prefer having the Option on the member definition. We can change that, but as a separate PR either before or after this one lands.

[Icxolu]

Thank you ❤️ I think this is a great start already. I left a few comments, mostly documentation related. We should also make sure to add a changelog entry for this.

[Icxolu]

Is there some page that we can link to where this mapping is documented for future reference?

[Icxolu]

Maybe we can add a comment here that slots 1-39 are type objects

[Icxolu]

Very nice 👍 Always great to have invariant encoded in the type system.

[Icxolu]

I think we need to look at the usages of this. These are used to conditionally cast structures, which we should not do anymore now that we are targeting a single ABI, right?

[Icxolu]

Maybe we can add a comment here that we are targeting the numpy 2 abi, and that is is abi compatible with numpy 1 for the api subset that numpy v2 exposes.

[Icxolu]

Smart, I like the syntax and that this can now support returning type objects from different APIs.