refactor!: allow subsets of dtypes and allow device-dependent dtype support

[ev-br]

Per discussion in gh-998 and the community meeting on Apr 30th,

• soften the requirement that all dtypes are implemented from must to should;
• require that at least one integer dtype and one floating-point dtype is actually supported (this allows us to not bother with edge cases of e.g. no floats at all);
• recommend that unsupported combinations of dtype=..., device=... raise an exception + specify that creation functions should raise. Note that this still leaves astype and to_device only implicitly specified and only covered by the recommendation to raise.
• specify that cross-device transfers in __getitem__ and __setitem__ are implementation-defined (and presumably covered by the recommendation to raise).

[rgommers]

Thanks @ev-br! One comment on a complex dtype not needing to be required, other than that this LGTM.

I considered whether to require specific types that are currently universally available (e.g., float32, int32), but that doesn't really help in any way while it does potentially create another issue if support shifts over time. So "one integer and one float dtype" seems just fine. In practice, libraries are going to just use them anyway and they will exist; actual code will rely on how to get things working with real-world libraries, not probing the must/should distinctions in the spec (that's mostly relevant for the test suite and authors of new array libraries).

[ogrisel]

LGTM.

[kgryte]

LGTM

[kgryte]

Looks like we have consensus. I will go ahead and merge and we can still tinker with guidance in the lead up to cutting the v2026 revision later this year.