Implement Polynomial for MultilinearExtension

[mmagician]

Description

This allows us to implement PolynomialCommitment directly for MLEs.

@Antonio95

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (master)
• Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests
• Updated relevant documentation in the code
• Added a relevant changelog entry to the Pending section in CHANGELOG.md
• Re-reviewed Files changed in the GitHub PR explorer

[mmagician]

One unfortunate consequence of this change is that now an MLE type has two implementations of evaluate, from MultilinearExtension and from Polynomial and we need to disambiguate the call, as seen e.g. here: f8e0378.

I think instead we can remove the evaluate method from MultilinearExtension, since both Dense and Sparse implement Polynomial, WDYT @Pratyush? This is done in 14eb52a

[Pratyush]

It seems that elsewhere in the crate, we assume that degree here represents total degree, and not individual degree. This is in agreement with mathematical convention.

So this should be changed to return self.num_vars, and it might be worth adding an individual_degree method to Polynomial that would return the degree for univariate polynomials, 1 for multilinear polynomials, and the actual individual degree for general multivariate polynomials.

[mmagician]

I adapted this to represent the total degree. I've also created a separate issue to discuss the exact design and the need for individual_degree: #692.

[Antonio95]

Is this method meant to represent a total degree bound, or the actual total degree of the particular instance this is being called on? For instance, the polynomial f(x, y, z) = xy + yz has num_vars equal to 3, but actual total degree 2.

Returning the actual total degree would be simple in the sparse case, but might require some work in the dense case if the polynomial is stored in evaluation form.

Incidentally, this caveat would also have applied to the code as it was before @Pratyush 's comment: we were always returning 1, but in the fringe case of constant polynomials, that did not match the total degree.

[Pratyush]

Ditto