Generalize lookups to set inclusion constraints

[vlasin]

After the discussion in #252, we arrived at the idea that ArithmeticCircuit is an intermediate representation of the computation that should allow an unrestricted ability to create polynomial, lookup, and fold constraints. If a particular proving system (e.g., Plonk) does not support a certain type of constraints, we convert them to the supported form during the protocol setup computation.

Given the above, we want to generalize the current lookup constraints to the inclusion checks:

$$ (x_1, \dots, x_{k}) \in T $$

Translating this to Haskell, we probably want T to be represented by Map and the tuple of variables to be a functor. We do not restrict the number of such sets T to be used in the same ArithmeticCircuit.

• Refactor ArithmeticCircuit type, replacing acRange field
• Refactor MonadCircuit and its instances

[TurtlePU]

during the protocol setup computation

Are we sure about this? Conversion will need access to quite low-level circuit APIs, doing this on the compilation stage seemed most reasonable.

Also this would help to keep protocol code dedicated to cryptography stuff only

[vlasin]

Well, I believe the conversion to the proof protocol format is a separate step. The workflow probably should go like this:

1. Compile the function to the IR of ArithmeticCircuit
2. Post-compile optimization (as a general rule, we want to optimize as we go, but it might not be always possible)
3. Convert to a proof protocol format
4. Protocol-specific optimizations (?)

So, we can wrap all 4 steps in a compile function whose output is a prepared setup of a specific protocol. But we should also have "internal" compile that only produces "ArithmeticCircuit". The latter, for example, is useful in IVC.