feat: add scalar support to element-wise functions

[kgryte]

This PR

• progresses Python scalars in elementwise functions #807 in adding scalar support to element-wise functions. The changes are restricted to element-wise functions in order to simplify review.
• updates the signatures for various dunder methods on the array object which did not indicate complex scalar support.
• reformats and consolidates some of the notes included in affected function signatures to a dedicated "Notes" section, as done for special cases. This moves ancillary specification guidance to "below the fold". A subsequent PR will perform a similar clean-up for APIs outside of those affected by adding scalar support.

[asmeurer]

I think we need to update and reference this section for the specification on how scalars convert into arrays. https://data-apis.org/array-api/latest/API_specification/type_promotion.html#mixing-arrays-with-python-scalars

[asmeurer]

And #841 if fixed will also potentially change how that text reads in relation to how real and complex scalar casting works.

[asmeurer]

clip is already an elementwise function that supports scalars, but we should ensure the language is consistent.

[kgryte]

In clip, which is slightly different in that the scalar arguments are optional, we already added guidance concerning differing data type kinds. However, we will still need to update to point to common documentation concerning scalar casting.

[ev-br]

Once python ints make the stage, I'd be ideal to explicitly spell the position on overflows. For both binary operators and elementwise functions. AFAICS, the spec only declares unspecified an attempt to cast a too-large python int to an integer dtype. However,

(Pdb) m32 = int(xp.finfo(xp.float32).max)
(Pdb) am32 = xp.asarray(m32, dtype=xp.float32)
(Pdb) am32
Array(3.4028235e+38, dtype=array_api_strict.float32)
(Pdb) am32 + m32
*** RuntimeWarning: overflow encountered in add
(Pdb) zzz = xp.asarray(m32*2, dtype=xp.float32)
*** RuntimeWarning: overflow encountered in cast

[asmeurer]

Also regarding clip: #811

[ev-br]

LGTM

[kgryte]

1. Common documentation. This is being addressed in a separate PR.
2. clip. The language is currently consistent. For that function, x must always be an array. Further changes are being addressed in separate PRs.

As such, I do not believe this PR has any blockers and has received one approval, I'll go ahead and merge. Any necessary updates can be addressed in follow-up PRs. Thanks everyone!