perf: Groth16 verifier

[yelhousni]

Description

currently we do GT == e(a1,b1)*e(a2,b2)*e(a3,b3) using Pair for the triple-pairing, which means computing the multi-Miller loop and then reducing it to a unique value with FinalExponentiation that should match GT from the VerifyingKey.
In this PR I wanted to check if including GT in the pairing computation (triple-pairing becomes quadruple) and using FinalExponentiationCheck (inside PairingCheck) would result in less constraints (using #1143, #1155, #1207).

N.B.:

• We can do better by implementing a QuadruplePairingCheck method that merges the squares of the equivalence check with the Miller loop (similar to perf: optimize DoublePairingCheck i.e. e(a,b)e(c,d) == 1 #1230 but for 4 pairs). I implemented this and it saves 5.7% but add more code to gnark that is only useful for G16 verifier circuit.
• We can keep GT in the VerifyingKey and include it the triple-Miller loop to compute the hinted witness residue. This also should work but again more specialized methods and more lines of code for a single circuit that we probably don't care about much.

Type of change

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

How has this been tested?

Tests pass.

How has this been benchmarked?

BN254-G16 verifier in a BN254 circuit:

• old: 1,455,104 r1cs
• new: 1,390,556 scs
• new (with QuadruplePairingCheck): 1,310,727 scs

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