✨ feat: add Quantity API

[nstarman]

This PR adds 2 runtime-checkable protocols that define the minimum Q API and the more complete API that includes the Array API. These protocols are made public in a new module named api.

private protocols and API are defined in the private modules _src/array_api and _src/api. The former is a temporary module that we can deprecate when the https://github.com/data-apis/array-api-typing package is developed and released.

Please squash-merge.

[nstarman]

@mhvk are you good to ignore RUF022? The __all__ are currently topically sorted.

[mhvk]

@mhvk are you good to ignore RUF022? The __all__ are currently topically sorted.

Sure, the sorting only starts to make sense when there are lots of entries. I don't think we're going to get there!

[mhvk]

This looks good, though with small queries inside. I do think if we expose anything, we should add tests for it. But I'm happy not to expose this yet, and instead just use it in the typing PR.

[mhvk]

Nice to have some tests. I made some in-line comments about testing u.Quantity and the various array types too, but then thought it was probably easier to just push an extra commit...

So, that leaves only a question about the __subclass_hook__ implementation. Will approve assuming that it is OK.

[nstarman]

@mhvk I refactored the tests to use pytest fixtures. They should be the same, just avoiding playing with globals.

[mhvk]

I thought about a structure like this when I wrote test_operations, but I rather dislike that it requiers every method to have that explicit fixture: I think setup_class() is considerably nicer: one just does tests on a given setup, which includes a given array type. Unfortunately, I could not seem to find a clean way in which one can properly parametrize classes by their setup, though I'll admit that I've never really understood the whole fixture process -- I find them rather unreadable (it seems pytest makes up its own language within a language rather than just using standard python stuff).

Anyway, long & short, I'd prefer to stick to one way of parametrizing over the array namespaces, ideally one that doesn't require to do setup in each method...

Since that is somewhat orthogonal to the goals of this PR, OK to just push back what I had and merge? (I'm definitely not stuck to my class creation code, but would like something that does not add boilerplate to each test!)

[nstarman]

Alternatively we can just make a class-scoped fixture (https://docs.pytest.org/en/7.1.x/how-to/fixtures.html#scope-sharing-fixtures-across-classes-modules-packages-or-session) by moving def array_and_quantity(request): into the class and adding the argument to the fixture. It neatly replaces class_setup.

[nstarman]

try running pytest in verbose mode, it now repeats the whole class as a block for each array library.

[nstarman]

If you merge, plz squash-merge, editing the comment.

[mhvk]

Not completely sold on the fixture for the general case still, but here it is very obvious what it does, so let's just get it in. Thanks, @nstarman!