Add pairing gadgets (depends on #26)

[dtebbs]

Moves many gadgets, including BLS12-377 pairing gadgets, from clearmatics/zecale, along with some accompanying interface changes.

[AntoineRondelet]

Moves many gadgets, including BLS12-377 pairing gadgets, from clearmatics/zecale, along with some accompanying interface changes.

@dtebbs Were the interfaces change needed for the code migration? If not, could we split this PR in 2 parts:

1. One that does the code migration
2. One that introduce code changes
   ?

Reviewing large chunks of code that are moved and mutated from one project to another is not the easiest, so I'd rather stick to 1 PR = 1 thing here and limit the scopes of the contributions to make it easier to review (and make the process less error prone).

[AntoineRondelet]

Also, one of the commit in this PR, i.e. bb8c106, seems to tackle: #11.

[dtebbs]

Moves many gadgets, including BLS12-377 pairing gadgets, from clearmatics/zecale, along with some accompanying interface changes.

@dtebbs Were the interfaces change needed for the code migration? If not, could we split this PR in 2 parts:

1. One that does the code migration
2. One that introduce code changes
   ?

In most cases the interface changes are tied in with moving the code
The problem is that most of the interface changes were required in the original code in zecale. So if we had one PR which simply moves the code and doesn't make innterface changes, then we would have places where 2 equivalent schemes have slightly different interfaces (so the lib would not be self-consistent and many tests could not be applied to some classes), and places where there are duplicates (the original libsnark version and tests, along side the libzecale versions).

Potentially we could create those PRs in the reverse order, i.e.

1. Apply the interface changes to all existing libsnark code
2. Move all libzecale into libsnark

If you think that would make a big difference then let me know and I'll look into it.

[AntoineRondelet]

where's generate_r1cs_constraints?

[AntoineRondelet]

Ok this interface has also been modified AFAICT, the _all_bits attribute isn't use anymore and the gen_constraints function seems to be missing.

[AntoineRondelet]

Ah, ok. this class seems to be the equivalent of libzecale::r1cs_gg_ppzksnark_verification_key_scalar_variable

[AntoineRondelet]

I'd add this function back to stick to the interface, as in https://github.com/clearmatics/zecale/blob/master/libzecale/circuits/groth16_verifier/r1cs_gg_ppzksnark_verifier_gadget.tcc#L138-L142
Even if the body is empty

[dtebbs]

Added the empty functions for now so this PR doesn't get side-tracked. However, going forward I'd be keen to have a better distinction between these "variable" types (which should only have a "generate_r1cs_witness" method), and genuine "gadgets". Added #36 with some notes (TLDR: these objects should not really be expected to have a generate_constraints method).

[AntoineRondelet]

Thanks for opening this ticket. I'm in favor or rethinking the distinction between gadgets and variables, but to keep the code consistent before we do so, and stick to the gadget interface, it's good to have this function added back. Let's revisit this in another PR.

[AntoineRondelet]

In most cases the interface changes are tied in with moving the code
The problem is that most of the interface changes were required in the original code in zecale

Ok I see. That's making this PR a little bit annoying to review since it moves quite a lot of code and the review is not simply about verifying the imports and namespaces etc but also tracking down the small interface changes spread across. That's fine, let's keep it that way.

[dtebbs]

LGTM, thanks @dtebbs Happy for you to rebase if you want to clean the history, and I'll merge the PR

Thanks @AntoineRondelet . Rebased onto origin/develop so should be ready to merge once the CI passes.