This modifies the scheme to be almost identical to the construction
outlined in Appenix A.2 of "Proof-Carrying Data from Accumulation
Schemes" (https://eprint.iacr.org/2020/499). The only remaining
difference is that we do not compute [v] U but instead subtract
[v] G_0 from the commitment before opening.
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.
