feat(honk): Shared relation arithmetic

[ledwards2225]

Description

Introduces a framework that allows the relation arithmetic to be shared between the prover and verifier.

The sumcheck prover and verifier accumulate the contributions from each relation (really, each sub-relation) into, respectively, Univariates and individual field elements. When performing relation arithmetic on Univariates, we introduce UnivariateViews to reduce full length Univariates to the minimum required length and to avoid unnecessary copies.

To share the relation arithmetic. we introduce simple structs that specify two types: Accumulators and AccumulatorViews. For the prover, who accumulates Univariates, these are respectively std::tuple<Univariate> and std::tuple<UnivariateView>. For the verifier, who accumulates FFs, both types are simply aliases for std::array<FF> (since no "view" type is necessary). The containers std::tuple and std::array are needed to accommodate multiple sub-relations within each relation, where, for efficiency, each sub-relation has its own specified degree.

Checklist:

• I have reviewed my diff in github, line by line.
• Every change is related to the PR description.
• I have linked this pull request to the issue(s) that it resolves.
• There are no unexpected formatting changes, superfluous debug logs, or commented-out code.
• There are no circuit changes, OR specifications in /markdown/specs have been updated.
• There are no circuit changes, OR a cryptographer has been assigned for review.
• I've updated any terraform that needs updating (e.g. environment variables) for deployment.
• The branch has been rebased against the head of its merge target.
• I'm happy for the PR to be merged at the reviewer's next convenience.
• New functions, classes, etc. have been documented according to the doxygen comment format. Classes and structs must have @brief describing the intended functionality.
• If existing code has been modified, such documentation has been added or updated.

[ledwards2225]

Note: this was an earlier iteration of the method instantiate_barycentric_utils, defined just above, which is the one actually being used. This was never meant to go in and this is the first I'm noticing it so I'm deleting it in this unrelated PR.

[kevaundray]

Since this only modifies honk related code -- marking this feature as non-breaking while the honk codepath not known to be used externally