Draft: #16806 - polar() obsolete, copied into polarm()

• This is step # 1. Please reopen #16806 after merging this MR, to clarify (and process) the documentation part for polarm().

ISSUE: To me, implementing polar() as the trivial function [abs(C), atan(imag(C),real(C))] = polar(C) is somewhat stupid because

1. It is really trivial. So, is it really useful?
2. It would be more useful at least by returning the phase as FISRT argout.
   Indeed, if we need only the moduli, then abs(C) does it, and that's all. We don't need polar() for that. While if we need only the phases, the expression atan(imag(C),real(C)) is also simple, but less trivial than abs(C).

I could (hardly, but well, yes) support publishing a new [Theta, Rho] = polar(C) syntax (with Theta first), because then it could work as an equivalent for Theta = angle(C).
While frankly, i do not see any interest in [Rho, Theta] = polar(C).

For the time being, the MR implements

• the new polarm() (OK)
• [Rho, Theta] = polar(C) extended to 2D non-square, N-D, and sparses C arrays
  [Rho, Theta] = polar(X,Y) for any real X and Y arrays

I let it as a draft. I can't vote for it as is. Moreover, unit tests are still missing.

• [Theta, Rho] = polar(X,Y) could be published without back-compatibility issue, since having 2 argins would be new.
• [Theta, Rho] = polar(sparse) : idem (even for square sparse: sparse are not supported by polarm())
  [Theta, Rho] = polar(nonSquare) : idem (not supported up to 2023.0)
• [Rho, Theta] = polar(square) can stays as is up to 2025.0: it redirects to polarm() up to 2025.0, and polarm() can stay forever with Rho first.
  BUT
• [Theta, Rho] = polar(scalar) : BROKEN, due to inversion of Rho and Theta.

Things would be easier (or just doable) by actually deprecating polar() and using a new function name. But which one? polarC() ?