fix: Store lagrange forms of selector polys w/ Ultra

[vezenovm]

Description

This PR switches to storing the lagrange form of all selector polynomials for the UltraComposer.

A bug came about while integrating this PR Noir's Rust backend: #249.
The lagrange forms of certain selector polynomials were missing from the proving key when it was read from a buffer. Thus, when it came time to construct a proof and the UltraProver attempted to fetch polynomials such as q_2_lagrange there would be an exception because the lagrange form was not in the polynomial store. The root of this cause was that the precomputed polynomials list was set explicitly when writing the proving key. For selector polynomials only poly IDs for monomials and ffts are included. This wasn't an issue for the DSL package with Turbo as the lagrange form of the selectors is never used. However, once we switched to using Ultra we needed the lagrange form of some selector polys such as Q_2, Q_M, table_value_*.

Rather than adding a new selector type and confusing the definitions of selector types, this PR opts for storing the lagrange form of all selectors polynomials for Ultra.

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.

[suyash67]

Looks good to me. One thing to note for future: writing of all selector polynomials' Lagrange forms would increase memory footprint of our prover (This is not an issue right now but could become one later. Since we are moving to Honk anyway, this should not be a long term problem though).

[codygunton]

Yeah, for a join-split circuit this is adding about 10MB of data to the proving key (most of which will be 0s, in fact). But I assume you have looked into alternatives, and I agree with @suyash67 that this is acceptable for now if it's blocking other work. Would please you add a note in ultra_selector_properties recording the old state and explaining why you've taken this shortcut?

[vezenovm]

Included a brief comment @codygunton let me know if more detail would be helpful