BUG: torch: accept Python scalars in binary elementwise functions

[raashish1601]

Closes #271 (also covers #410).

torch.maximum, minimum, atan2, hypot, logaddexp, nextafter and logical_and/or/xor reject Python scalars, and equal, not_equal, less, less_equal, greater, greater_equal and copysign reject a scalar as the first argument. The 2024.12 standard allows a scalar in either position.

Following the idea in the issue, _two_arg now takes scalar_x1 / scalar_x2 flags. When set, a Python scalar in that position is converted to a 0-D tensor with result_type(scalar, other) on the other argument's device. The flags are only set where torch rejects the scalar, so calls that already work (e.g. add(x, 1)) take the same path as before. nextafter and the logical functions are now wrapped too and added to __all__.

from array_api_compat import torch as xp
xp.maximum(xp.asarray([1., 2.]), 1.5)   # was TypeError
xp.less(1.5, xp.asarray([1, 2]))        # was TypeError

Testing: removed the matching test_binary_with_scalars_* entries from torch-xfails.txt; those 28 tests pass locally against array-api-tests, along with the rest of test_operators_and_elementwise_functions.py and test_signatures.py. Added tests to tests/test_torch.py; they fail on main and pass with this change. ruff check . passes.

[mdhaber]

The flags are only set where torch rejects the scalar, so calls that already work (e.g. add(x, 1)) take the same path as before. nextafter and the logical functions are now wrapped too and added to __all__

I'd suggest that it's not worth the extra complexity to figure out precisely when torch rejects scalars and use scalar_x1/scalar_x2 to interfere only in the problematic cases. Just check that at least one is a tensor (and raise if not), determine the result_type, and use xp.asarray(..., dtype=dtype) on both. You can eliminate the scalar_x1/scalar_x2 arguments (unless there are functions that don't accept Python scalars for one of the arguments), and the diff gets a lot smaller. If this is problematic for any reason, we take it as impetus to fix the problem at the source rather than add a more complex workaround here.

[mdhaber]

IIUC, there are two tests (conceptually) that we want to perform for all these functions:

1. check that passing in one array and one scalar produces the same output as if the scalar had been passed in as an array of the correct dtype.
2. check that passing in two scalars raises an error.

So I think one function could perform the first test, parametrized over all the dtypes accepted by each function, and a second function could perform a simpler check for the error.

(Or, personally, I would just as well ignore the requirement that one argument must be an array. NumPy functions don't care, and torch.result_type is happy with two scalars, so why shouldn't these two-arg functions accept two scalars, too? This would eliminate the artificial requirement of checking for Python scalars/raising and for the second test.)