Refactor to prepare for WHIR Integration

[b-wagn]

This PR does a major refactoring of the codebase with the aim to allow integrating zkVMs that are based on WHIR.

Related to #19

Status

• Make name, soundness, proof size, parameters functions of the zkVM
• Split zkVM into subclasses (FRI-based, WHIR-based, or even more later)
• Re-integrate best attack
• Re-integrate printing of parameters
• Define WHIR parameters
• Add computation of WHIR security levels
• Add computation of WHIR proof sizes
• Create a dummy WHIR VM to test things
• Re-integrate md report

Note: right now, the regimes are still FRI specific. We may later consider defining a general "prox gaps regime" module, which outputs the bounds and can then be used by both FRI and WHIR regimes. I would recommend doing that once we have integrated WHIR.

[asn-d6]

Thanks for all the work! Fixed a bug, and revived the markdown.

Some thoughts on the refactoring:

• regimes/fri_regime.py seems a bit weird, as FRI is definitely not a regime. What's the plan? How much of regimes/ do we think will also be useful for WHIR?

• A side-effect now is that there is a bunch of FRI stuff scattered across the modules. An alternative structure (not sure if it's better) would be to make a soundcalc/FRI/ directory and put there all the FRI stuff there, including zkvms/fri_based_vm.py and common/fri.py. Then introduce a soundcalc/WHIR/ directory. What is not clear to me right now is how much code will be shared between the FRI and the WHIR module (probably some of the proximity gaps stuff).

[b-wagn]

Thanks for the review and the progress :)
About your questions:

FRI-Regimes: I agree that it is a bit weird. In the long term, I think we should have proximity gaps / CA regimes and both WHIR and FRI VMs should call them to get their soundness errors. Right now, the reason why it is still called FRI-regime is that the functions that it provides are still FRI-specific, e.g., the name get_commit_phase_error does not make a lot of sense for WHIR. My strategy would be to keep the regimes FRI-specific for now, then integrate WHIR, and then see how much code is shared and move it into a separate proximity gaps module.

Structure: I think what you propose here makes sense to me. Btw, it was a bit tricky to avoid circular dependency between modules here, which is why the class FRIParameters was introduced.