Perf: Groth16 verifier circuit with pre-computed lines

[yelhousni]

Description

(This PR includes #874)

Currently the verification computes the multi-pairing check:
e({kSum, proof.Krs, proof.Ar}, {vk.G2.GammaNeg, vk.G2.DeltaNeg, proof.Bs}) == vk.E
where proof.Bs is a variable G2 point (part of the proof) but vk.G2.GammaNeg and vk.G2.DeltaNeg are fixed G2 points wrt to circuit (part of the SRS).
Similarly to #874, we can use a fixed-argument multi-Miller loop for
ML({kSum, proof.Krs}, {vk.G2.GammaNeg, vk.G2.DeltaNeg})
and a normal (variable-argument) Miller loop for
ML({proof.Ar}, {proof.Bs})
and then multiply them and apply the final exponentiation step on the result.

Note: we can further merge the squarings and the lines multiplications inside the two Miller loops but we would need to implement a generic MillerLoop that deals with the second arguments being variable or fixed — or have a specific method for 3 pairings where 2 are fixed-arg. This is more work given that we have already a good SCS reduction and Groth16 is not a priority. However for R1CS we lose some constraints.

Type of change

• New feature (non-breaking change which adds functionality)

How has this been tested?

Curent tests in std/recursion/groth16.

How has this been benchmarked?

• Emulated case: verifying a Groth16 proof on BN254 with a BN254-SNARK:

	Old	New
R1CS	2,626,480	2,529,489
SCS	13,697,831	13,309,620

This is 96991 R1CS and 388211 SCS saving.

• Native case: verifying a KZG proof on BLS12-377 with a BW6-761-SNARK:

	Old	New
R1CS	20,148	20,401
SCS	82,481	87,994

This is 253 R1CS and 5513 SCS increase! That's not terrible but allows to have a generic interface for both emulated and native G16 recursion.

Checklist:

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I did not modify files generated from templates
• golangci-lint does not output errors locally
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules