support different backends

[mimoo]

Currently only plonk (specifically kimchi) is supported. I'd be cool to be able to support different backends, specifically snarkjs which has quite the amount of traction.

I'm wondering about several potential paths here, and I'm not sure which would make more sense:

• would it make sense to be able to dump to an R1CS/plonk format that circom can understand? Specifically, circom implements optimizations for R1CS and it might be possible to run them on noname if we dump the constraints in the right format
• would it make sense to be able to dump to the same format that circom compiles to? So that we can directly use noname compiled artifacts with snarkjs?
• in general, it would be cool to be able to choose r1cs as a backend (via some --r1cs flag) and noname would dump r1cs constraints/witness instead (I think it shouldn't be too hard, as in: the public input should have the value 1 be the first value, the witness symbolic table would have a single column (z), constraints would add to matrices a, b, c instead of adding plonk custom gates to the gates array

[mimoo]

I think these are the steps we should take:

1. make the circuit-writer (or noname in general) generic based on Field (different proof systems use different fields). Right now we hardcode the field to Pallas' base field. So something like pub struct CircuitWriter<F> where F: ark_ff::Field is probably a good start.
2. move all the kimchi fields (witness_vars, rows_of_vars, gates, wiring, double_generic_gate_optimization, pending_generic_gate) to some kimchi-related struct, then make sure that code compiles
3. modularize the circuit-writer: have an enum that allows you to choose between R1CS or Kimchi, fix compiler errors. We might be able to reuse some data structures from arkworks
4. at this point anything R1CS should be unimplemented!(). Try to compile simple examples like arithmetic.no with R1CS arithmetization

[mimoo]

current progress: @katat has a nice trait for Backend that different backends can implement. We now realize the goal is to move as little as possible to the backend trait, so that most code remain the same between backends. There's some refactors needed in builtins, as well as fields, to make things generic on the backend or field