docs: clarify clip behavior when arguments have different data types

[kgryte]

This PR

• follows up on docs: clarify that clip behavior is undefined when min or max is outside the bounds of x #814 (comment) and Python scalars in elementwise functions #807 and supersedes feat!: allow clip to have int min or max when x is floating-point #811 to indicate that behavior is only defined when min and max have the same data type as x. After reviewing SciPy and scikit-learn usage of xp.clip and np.clip, the overwhelming usage was using scalar min and max. For all instances that I found with array min and max, type promotion behavior was not expected. Given the various edge cases when min and max are not the same type as x, it seems prudent to limit portable behavior to the scenario which avoids edge cases altogether.
• clarifies the definition of clamp as suggested in docs: clarify that clip behavior is undefined when min or max is outside the bounds of x #814 (comment).
• specifies behavior when min and/or max are scalar values.
• clarifies three-way broadcasting as done in feat!: allow clip to have int min or max when x is floating-point #811.
• relaxes the output array data type requirement in order to accommodate libraries such as NumPy which support type promotion behavior and cannot adopt a stricter implementation due to backward compatibility concerns.
• backports a typo fix to the v2023 revision.

[rgommers]

Thanks @kgryte. Looks good overall, one minor comment about phrasing how Python scalars are handled.