feat: allow subsets of dtypes, 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 dtype per category is actually supported (this keeps excluding array libraries which do not have complex types at all, but 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).

[rgommers]

I don't think complex should be added here, rather bool and one integer and one real floating-point dtype must be supported.

[ogrisel]

That would be enough for scikit-learn at least.