Support `PrefixOp` expressions.

[brech1]

Add support for the PrefixOp expression.

• https://docs.circom.io/circom-language/basic-operators/#arithmetic-operators

[voltrevo]

@brech1 I have a wip branch here but I've run into some questions/issues:

1. Should new unary gates be supported in the output format? Or should we be compiling to the existing format somehow? a. Is the format specified somewhere?
2. How should -x (ExpressionPrefixOpcode::Sub) be handled? Should a u32 underflow? Or perhaps emit a compilation error?

[brech1]

1. Thank you for bringing this up, so I think the supported gates are determined by our backend target, and so far in mpz these are available:

pub enum ArithGateType {
    /// Addition gate.
    Add,
    /// Subtraction gate.
    Sub,
    /// Multiplication gate.
    Mul,
    /// Constant multiplication gate.
    Cmul,
    /// Unary projection gate.
    Proj,
}

So perhaps we should update the gates we're supporting. This is also related to this comment @namnc left in the overview. There is no defined format.

2. If an assignment to a gate is only -x I think it would be equal to 0 - x so perhaps declaring a constant 0 as the other gate input for a subtraction gate. I think this and other cases should be handled individually in a new handle_prefix_op function, if it gets too long.

[namnc]

For simplicity let's (for now) stick to binary gate and have x = 0 - x for negation.

[namnc]

Point 2 is another issue itself. Rigft now we consider only u32 (behind the scene we do wraparound so -p becomes M-P with M being the bound of the value) but we should also consider i32? This is related to typing.

[brech1]

For simplicity let's (for now) stick to binary gate and have x = 0 - x for negation.

And what should we do regarding the amount of gates we're supporting (more than the supported by the backend)? Should the backend handle this? Perhaps MP-SPDZ have a broader support?

Point 2 is another issue itself. Rigft now we consider only u32 (behind the scene we do wraparound so -p becomes M-P with M being the bound of the value) but we should also consider i32? This is related to typing.

Even if we add the i32 type we have to handle overflows and underflows on unsigned. We could add a configurable mod integer so we can implement modular arithmetic with it, this would only be applied on integer operations.