The Lagrange interpolation we were doing was pointless. kate_division sheds the constant
term off each time it is invoked because the quotient polynomial isn't affected by it.
This means we were modifying coefficients that end up getting discarded anyway; the
quotient polynomial coefficients are already determined exactly by the leading coefficients
and the fact that a root exists at each of the points.
Previously, `ChallengeScalar` could use the operator traits defined on
the `F: Field` type it wrapped, due to its `impl Deref<Target = F>`.
This was technically ambiguous, and Rust 1.49.0 makes that ambiguity an
error.
We could fix this by adding operator impls with `ChallengeScalar` on the
RHS, but that would conflict with zcash/halo2#111. Instead we manually
dereference every challenge scalar when used in an arithmetic operation.
The argument to the poly::commitment prover and verifier was mistakenly
represented as a challenge, when in fact the commitments may be opened at
any scalar (which just happens to be a challenge within poly::multiopen).
The poly::commitment APIs are now public again.
