Support C->R case

[Randl]

Supersedes #71

I've lost the bandwidth when we figured out we can't support C->R functions in lineax, which seemed to require a major rewrite.
Thanks to AI and some free time, I figured that at least for the optimistix (and hopefully downstream diffrax) case we can solve the problem quite elegantly without too much hustle. This is fully transparent to the user, who shouldn't care about the underlying C->R^2 conversion.

Closes #76

[patrick-kidger]

So I remember considering this approach back when we were first exploring complex numbers. I think the main problem with this is how it affects the underlying linear solves. Each step of most nonlinear solvers involves an O(n^3) linear solve.

If we expand out real/imaginary parts, then n->2n, and the cost of each nonlinear solve goes up by a factor of 8.

I think the fact that we operate over specifically complex numbers, and not arbitrary 2n-many values, might make it possible to do better than this?

That said, I am also aware that right now our complex support is "not really there", so maybe this is still an improvement on the status quo. And as you note, it's certainly a simple one. WDYT?

[Randl]

I'm not sure if a factor of 8 is a real thing. First, multiplying two complex numbers takes 4 FP operations, not 1. Second, if the operator is C->R, then only the input dimension is doubled.
Third, since C->R functions are never holomorphic, I don't think there's much structure to exploit, since d/dz isn't enough information and you need d/d\bar{z} (or equivalently d/dx and d/dy, which we do). It may be worth looking into specific optimizations for some cases, but for the general case I don't think there is anything there, unless I'm missing something.