feat: add complex dtype support for mean

[kgryte]

This PR

• resolves RFC: add support for complex input to mean #846.
• adds support for complex data types when computing the arithmetic mean.
• includes special cases which deviate from NumPy et al, but are consistent with real-valued floating-point special cases as outlined in the specification. Namely, if the arithmetic mean is computed as a sum followed by scalar division, then NaN components should only propagate relative to the respective component. However, in NumPy, given array([ 1.+0.j, 2.+0.j, nan+0.j]), NumPy will return nan+nanj when invoking np.mean.

[rgommers]

• includes special cases which deviate from NumPy et al, but are consistent with real-valued floating-point special cases as outlined in the specification. Namely, if the arithmetic mean is computed as a sum followed by scalar division, then NaN components should only propagate relative to the respective component. However, in NumPy, given array([ 1.+0.j, 2.+0.j, nan+0.j]), NumPy will return nan+nanj when invoking np.mean.

PyTorch, JAX and CuPy all yield the same nan + nanj result as NumPy. I don't think it's very useful to specify a special case like this, since it'll just be ignored and in practice be wrong. So I'd at least use "should" rather than "must".

It's possible the behavior in NumPy may change (following CPython's change for division): numpy/numpy#26560.

[asmeurer]

I thought we had decided at some point that the distinction between things like 1. + nanj and nan + nanj is generally undefined in the standard (or am I just remembering a similar discussion about infinites?).

I've certainly taken that view in some places when implement things, taking something like "the result should be nan" to mean isnan(x) should give True, which is the case if either or both components are nan.