transpile: Refactor binary operand handling and handle complex numbers

[Rua]

Both a refactor and a functional improvement. Complex numbers aren't supported yet, so I haven't included any tests for that, but this is needed to support them later.

[ahomescu]

Could you add a test or two for this (unit and/or snapshot)?

[Rua]

Not really sure what to test for, that isn't already tested?

[ahomescu]

Okay we can land this as is since it's a pretty small change, but it would be nice in the future if changes were split between 1) refactorings (no tests needed), and 2) actual functional changes, that would need a test or two to handle those specific corner cases.

[ahomescu]

What if result_type_id is already a Complex? Would something like double f(double _Complex a, double _Complex b) { ... a + b ... } panic here? That could be a new test.

[Rua]

If it's already a Complex then it would either stay the same, or be replaced with the complex version of one of the PULLBACK_KINDS, same as happens with other numeric types right now. The code here only applies to binary operators, so it won't modify a function call.

[ahomescu]

My point was: is it incorrect to create a type like CTypeKind::Complex(Complex(...))?

[Rua]

In C, yes.

[ahomescu]

Can you check if the following C functions cause transpiler panics?

double _Complex f(double _Complex a, double _Complex b) {
    return a * b;
}

double _Complex g(double a, double _Complex b) {
    return a * b;
}

typedef double real;

double _Complex h(double _Complex a, real b) {
    return a * b;
}

[Rua]

Hmm, it does, and I see the problem now. I managed to fix the first two cases, but the third one still panics because of the typedef. No real _Complex type exists. I need to think of a way around that...

[Rua]

Ok, I've completely rewritten that part of the code. It should be good now?