`PolynomialCommitment` trait simplification

[mmagician]

Summary

The PolynomialCommitment trait is a little cumbersome with all the wrapper types. See if we can simplify the trait and then implement it for all schemes. Some ideas:

• [ ] rename check -> verify- there are a lot of name variations in the literature for the same algorithm, though check seems to be used less frequently. verify is more intuitive IMO.
• [ ] LabeledPolynomial construction is cumbersome: introduce a from conversion on Polynomial<F> with some reasonable defaults, or:
• [ ] combine it with the trim function, which would take the parameters from the max degree of all labeled polys we are working with.
• [ ] infer QuerySet from a vector of (vectors of?) points. Construct Evaluations from QuerySet and a Vec<Polynomial>.
• [x] can we construct the ChallengeGenerator automatically? We know the sponge, and we know whether the poly is uni- or multi-variate, so this can be part of e.g. setup.
• [ ] split the trait into a "base" trait and "batched" trait (?)
• [ ] document all the methods

See also jellyfish PCS trait, although the Espresso traits aren't as generic as they are mostly tailored for KZG. @alxiong

---

For Admin Use

• [x] Not duplicate issue
• [x] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[mmagician]

We'll use this issue to keep track of various pain points in the interface so maybe we can iterate on it. Some more ideas:

• trim function only supports univariate polys (since degree is always 1 for ML). E.g. the only multilinear PCS in the crate doesn't follow the PolynomialCommitment trait pattern (perhaps this is one of the reasons) and instead implements the same methods (more or less, but with simplified signatures) as stand-alone on the struct.

[mmagician]

Actually, one very natural extension of a point I already describe in that issue: split the trait into a "base" trait and "batched" trait is the following: split the commit/open/verify functions into being able to work with single vs. multiple polys. Place the {commit/open/verify}_single into the base PolynomialCommitment trait and {commit/open/verify}_multiintoPolynomialCommitmentMultiPoly: PolynomialCommitment`.

Note that this is different than batched, which refers to num of points being opened, IIUC.

That simplification automatically removes the need to be generic on S: CryptographicSponge (since the sponge is used for taking RLC of polys) and allows for a much more natural interface like the one that multilinear_pc offers. TBD how much boilerplate around combined_polynomial += (curr_challenge, polynomial.polynomial()); can be re-used later in the _multi methods.

[autquis]

So far, the ChallengeGenerator was removed in #139.