Improvements to Abstract Sumcheck Module

What:

• abstract_sumcheck module's prove function now returns ReducedClaim<F> rather than EvalcheckClaim<F>
• abstract_sumcheck module's batch_prove function now return Vec<ReducedClaim<F>> rather than Vec<EvalcheckClaim<F>>
• Drive-by improvements (e.g. improving GKR sumcheck test, e.g. sorting (and unsorting) the Vec<ReducedClaim<F>> output of the abstract_sumcheck::batch_prove protocol to ensure that the order of output matches the order of the input provers (or input claims))
• Highlighting this last thing --> before this PR evalcheck claims are being returned in a different order than the input abstract sumcheck provers/claims are being passed in. This has not been an issue yet and it's not technically wrong, but a user of batch_prove could reasonably desire the invariant that the ith input claim maps to the ith output claim.

Why:

• Not all modules that used AbstractSumcheck wants the prove output to include EvalcheckClaim. One such example is the gkr_sumcheck module, as the multilinears involved in the gkr_sumcheck protocol are not necessarily committed to, existing only in the head.
• Code in abstract_sumcheck module need not be aware of evalcheck or oracle at all
• ... with the exception of one useful helper method (pub fn finalize_evalcheck_claim<F: Field>) that has been placed in abstract_sumcheck::abstract_sumcheck module for code deduplication (this method turns a ReducedClaim<F> into an Evalcheck<F> when given CompositePolyOracle<F> advice

Useful Future Improvements (Out of scope for this PR):

• Refactor batch_prove in all three modules (sumcheck, zerocheck, gkr_sumcheck) to take in witnesses and claims rather than an iterator yielding AbstractSumcheckProver
• Once we make these refactors in sumcheck and zerocheck modules to take in witnesses and claims, we can remove oracle as a field from the SumcheckProver and ZerocheckProver