Improve legibility and methodology for testing opcode circuits

[bgillesp]

Currently, RISC-V opcode circuits are tested individually in a mock prover using hand-crafted operations added to ceno_zkvm/src/scheme/mock_prover.rs, and (sometimes) using the real prover in a single example program at ceno_zkvm/examples/riscv_opcodes.rs. The methodology for implementing this testing could likely use some improvements in terms of:

• Legibility, e.g. providing a more usable interface for specifying and implementing tests for circuits
• Coverage, e.g. ensuring that all implemented RISC-V functionality is tested in both a mock prover and a real example program

[bgillesp]

See also comments by @matthiasgoergens posted here

[naure]

The point is that this is how the spec is written. So we can tell the exact data being tested without intermediate code.

But yes it is getting out of hand.

• We could add convenience constructors to DecodedInstruction for instance. Then do include tests for the test utilities tying it back to the raw values from the spec.
• The constants in mock_prover.rs could be replaced by some functions that give the instruction and the PC together.

[KimiWu123]

I submitted a short PR #395 to address the constants in mock_prover.rs, and would like to raise some discussion and hear your feedback. If this PR makes sense to you, I'll keep working on all the opcode tests.

cc. @hero78119

[matthiasgoergens]

The point is that this is how the spec is written. So we can tell the exact data being tested without intermediate code.

If you want to test against the spec like that, you should just use the official RiscV tests.