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]

A 70 line implementation of NEP-50. How cool is that?

[lezcano]

Does this happen just for uint8 or for any int dtype?

[lezcano]

Also, using .item() is not kosher. Let's do 0 <= weak < 2**8 before doing the as_tensor.

[ev-br]

This is a bit different: checking the weak's value does not detect uint(100) + 200. However, numpy warns not raises, so we shouldn't raise either. As discussed, this PR now does what numpy does, sans RuntimeWarnings.

[lezcano]

Also, it's a bit annoying that this check is just done for ints. If it were done for all dtypes, we could create the tensors with torch.full, which does check if the number fits in the given type.

[seberg]

I think that is also a valid choice, numpy already gives a customizable warning anyway if you overflow to inf, so this just seemed the easier/OK thing. ints don't overflow graciously though...

[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