Feat/fold pedersen

[Tabaie]

In anticipation of multicommits for Groth16, this PR provides the possibility to verify multiple proofs of knowledge for Pedersen commitments more efficiently (by consolidating MSMs, generating the proof might be a bit faster as well)

Similarly to KZG, a value $r$ is obtained from a single-challenge Fiat-Shamir object using byte arrays provided by the user (the reason for custom byte arrays explained later.) Then instead of shipping $\set{(C_i, \pi_i)}_i$ where $C_i$ are commitments and $\pi_i$ the corresponding proofs of knowledge, the prover sends $(\set{C_i}_i, \pi \coloneqq \sum_i r^i\pi_i)$.
The verifier in turn computes $C \coloneqq \sum_i r^iC_i$ and instead of checking $e(C_i,g)=e(\pi_i,g^{1/\sigma})$ multiple times, checks once that $e(C,g)=e(\pi,g^{1/\sigma})$.

From the user's perspective, the breaking change is that the function pk.Commit does not yield a proof of knowledge anymore. A later call to pk.ProveKnoweldge or pedersen.BatchProve will be necessary. Another potentially annoying change is that pedersen.Setup returns ([]ProvingKey, VerifyingKey, error) instead of the previous (ProvingKey, VerifyingKey, error) so even a user that is dealing with one commitment only has to deal with a slice and write lines like pk[0].Commit....

Remark: Normally in Fiat-Shamir one would expect hashing all the commitments that are to be verified, perhaps along with a nonce coming from the user. However, if we allow the user to take control of this, in the Groth16+Commitments verifier we could hash the representations of the commitment values in Fr, rather than the larger group elements. An alternative could be for the Fold functions to hash the compressed representations of the commitment values directly. Would welcome your input on this design choice.

[ThomasPiellard]

lgtm, just to be sure could you add a test where a proof is tampered to check that it "fails successfully ^^" ?