Standardize "pinned" dtype promotions

Start with the linked specifications for setitem, in-place operators, clip, nextafter, and the dtype promotion page. Compare their current rules with the proposed pinned or bound promotion behavior; done means the general rule and the affected function references clearly define the scalar and mixed-dtype cases.

These functions:

• __setitem__
• __iadd__ and other in-place operators
• clip
• nextafter

Have in common that the output dtype must match the dtype of the first parameter. This is unlike most other binary or ternary functions, where all parameters are free to be be promoted against each other.

Q: Are there other such functions?

Beyond this, however, these functions differ substantially in the details:

First parameter is a Python scalar

• in __setitem__, __iadd__, and clip, the first parameter must be an array. This is an obvious necessity for __setitem__ and __iadd__, because it's a method, but not for clip.
• in nextafter, the first parameter can be a Python scalar int | float. The spec is not clear on what must happen in this case; I interpret it as "the output dtype must be the dtype of x if x is an array, otherwise follow the normal dtype promotion rules and return float32 or float64 depending on the dtype of y." It could use an explicit clarification.

Second parameter is an array of different dtype

• In __setitem__ and __iadd__, if the second parameter (value) is an array it can be automatically promoted to the dtype of the first parameter (self).
• In clip, behaviour is undefined. Which to me is weird, because the result would be unambiguous in all cases where minimum and maximum are defined and have an output dtype matching the first parameter - for example, clip(int16, min=int8, max=int8).
• In nextafter, behaviour is also undefined, which again to me is weird because it is unambiguous in all cases where __lt__, __gt__, and __eq__ are defined; in other words nextafter(float64, float32) is unambiguous.

Proposed changes

• Allow clip to have the first parameter as a Python scalar, like it already happens in nextafter
• Allow min and max parameters in clip and the y parameter in nextafter to be arrays of a dtype promotable to x.dtype, like it already happens in __setitem__
• Add a section to the dtype promotion page for "pinned" or "bound" dtype promotion, defining a general rule
• Have __setitem__, clip, and nextafter point to this general rule