* Draw challenge points from the extension field
* Now building
* Misc
* Default eval_unfiltered_base
* fmt
* A few field settings
* Add to Sage
* Display tweak
* eval_filtered_base
* Quartic in bench
* Missing methods
* Fix tests
* PR feedback
Over quartic field extension (for now). This would be used in our FRI recursive verifier later, for the consistency check.
To summarize the wires,
- `n` inputs for the `n` points to interpolate (don't need `4n` since they'll be in the subgroup of the base field)
- `4n` inputs for the `n` (extension field) values to interpolate
- `4` inputs for the point to evaluate the interpolant at (beta, which will be drawn from the extension field right?)
- `4` outputs for the interpolated value
- `4n` internal wires for the interpolant's coefficients
This definitely isn't the most optimal approach, e.g. we could route in a single "base" point and derive its neighboring points, but just wanted to keep it simple for now.
If we did it all with `ArithmeticGate`s, the main loop (with ~101 iterations of cubing and a couple adds) would be fairly expensive, so this uses a (much smaller) custom gate called `GMiMCEvalGate` which does all the computations for one iteration of that loop.
As discussed, it seems like the batch opening argument will be a significant cost, and we can reduce that cost by not including shifted openings (except for `Z`s which need them).
... and other minor refactoring.
`bench_recursion` will be the default bin run by `cargo run`; the otheres can be selected with the `--bin` flag.
We could probably delete some of the other binaries later. E.g. `field_search` might not be useful any more. `bench_fft` should maybe be converted to a benchmark (although there are some pros and cons, e.g. the bench framework has a minimum number of runs, and isn't helpful in testing multi-core performance).
