clarify our strategy on how opinionated the compiler is (i.e how much does it assist circuit developer)

[gbotrel]

see for example #552 ;

We can have 2 strategies;

1. at compile time we can detect some unsatisfiable constraint (like api.AssertIsEqual(2, 4) ) and panic.
2. we add the unsatisfiable constraint, and wait until we solve the constraint system to throw the error.

And I think it generalize well into "how much do we want to assist the circuit developer";

1. Has the advantage to be more dev-friendly; catching mistakes like this early on makes for a better dev workflow.
2. is cleaner and gets us better testability (same code paths everywhere, etc). it also allows for things like SMT solver integration (where we may want to add "unsolvable constraint" and ensure that indeed, the whole system is unsolvable; that is detect bugs in the compiler).

We could log potential errors early on, but we lose the "cleaner" part of 2 (we will have in each api to implement this warnings anyway).

[gbotrel]

• I think we will still test for constants in many places; for example; api.AssertIsEqual(3,2) --> should we really add in the constraint system a constraint that says "(3-2) == 0" ?