ENH: introduce NEP 50 "weak scalars"

[ev-br]

Make python scalars "weak" [1], meaning that in type promotion, they do not type promote arrays:

(np.int8(3) + 4).dtype == int8

• Note that array scalars (np.int8(3) etc) are 0D arrays, so they are not weak.
• Converting a weak scalar to an array (asarray(3) etc) makes it not weak.
• Scalars are only weak in ufuncs. In places like np.dot([1, 2, 3], 4.0), the result is float64.

[1] https://numpy.org/neps/nep-0050-scalar-promotion.html

This is an alternative to gh-137, which it supersedes and closes.

NB: tests fail. The majority of failures are, I believe, in internals of torch_np.testing which are vendored from numpy. And that is incredibly messy, so they are due in for a face-lift. Am migrating them to rely on torch.testing.assert_close.

[ev-br]

Grrr, no. There's more to NEP 50. Converting to draft for now.

[ev-br]

CI's green, finally! There is one more known failure, will need to special-case complex <op> float32 promotion path. Will also add some more tests along the lines of https://gist.github.com/ev-br/27dee81aae8e24193db8082ee886f6e4 . Other than these two, this is ready.

[ev-br]

Based on an off-line discussion with @lezcano , this PR now:

• all NEP 50 handling is confined to binary ufuncs
• we define a special annotation/normalization, ArrayLike | Scalar, where python numeric scalars do not get converted to tensors
• this annotation is only used in binary ufuncs.

[lezcano]

Perhaps @seberg could have a look at this one as well?

[seberg]

The truly complicated stuff is if you have more than 2 operands, without that, this seems fine (no you cannot just do a reduce(two_op_result_type, values)).

I am not actually sure about that dot example, not that dot worries me, but overall the issue remains a bit that some functions effectively call np.asarray() on entry, and thus disable any chance of "weak" handling. And... I have not figured that out fully, we may want to move more functions to weak handling.

(OTOH, I do feel that beyond ufuncs the issue is probably small enough that missing a few functions isn't the end of the world.)

[ev-br]

OK, two updates:

• this all is needed in a subset of binary ufuncs only (add, multiply etc). Comparisons must be exempt (consider np.uint8(1) > -1), not sure about other things (np.hypot?). So guard it with an explicit whitelist
• this interacts with set_default_dtype :-). Since NEP50 is numpy-specific, I'm just checking if the defaults are those from numpy, and bail out otherwise.

[ev-br]

This PR now includes @lezcano 's updates from gh-143