Add complex number support to linalg.slogdet

[kgryte]

This PR

• adds complex number support to linalg.slogdet.
• defines the sign of the determinant in agreement with Add complex number support to sign #556. In contrast to its sign function, NumPy uses the definition $\operatorname{sign}(\det x) = \frac{\det x}{|\det x|}$ to compute the sign of the determinant. At the time of this PR, PyTorch refers to the "sign" as the angle (which I take to mean the argument of the determinant); however, I don't believe this is correct, as, via polar decomposition, $\det A = |\det A| e^{\theta j}$. Given the expected equality that $\det A = \operatorname{sign}(\det A) \cdot e^{\ln |\det A|} = |\det A| \operatorname{sign}(\det A)$, we see that what should be returned is $e^{\theta j}$, not simply the argument $\theta$. While the PyTorch docs state that the angle is returned, what is actually returned is $\frac{\det x}{|\det x|}$.
• updates the allowed data types from real-valued floating-point to any floating-point data type.
• requires that the sign array be the same data type as the input array and logabsdet be unconditionally real-valued.
• adds an extended description describing the operation.
• makes explicit that, for matrix stacks, a solution must be computed for each matrix in the stack.

[rgommers]

... we see that what should be returned is $e^{\theta j}$, not simply the argument $\theta$. While the PyTorch docs state that the angle is returned, what is actually returned is $\frac{\det x}{|\det x|}$.

I think that that's mostly a terminology thing? The implementations are consistent:

>>>x=np.array([[0.1+0.9j, 0.5-0.5j], [1, 2j]])
>>>np.linalg.slogdet(x)
((-0.9566738804288585+0.29116161578269606j), 0.877201841342143)
>>>torch.linalg.slogdet(torch.as_tensor(x))
torch.return_types.linalg_slogdet(
sign=tensor(-0.9567+0.2912j, dtype=torch.complex128),
logabsdet=tensor(0.8772, dtype=torch.float64))

If there's something to clarify or improve in the PyTorch wording in the slogdet description, that's of course useful. @lezcano since you wrote those docs, you may want to have a look at the comment in the PR description here.

[rgommers]

Changes here LGTM, thanks @kgryte

[lezcano]

I agree that the term angle is not correct. The quantity that's returned in PyTorch is indeed the sign, and the rest of the docs and the implementation are consistent with this. I'll fix that in the PyTorch docs soon.