Draft: RISC-V: Provide shape object for deserialisation

Closes RV-555

What

Provide a valid implementation for the octez_riscv_deserialise_proof method for the ocaml api.

Why

This enables the rollup node and the protocol to obtain a proof from raw bytes.

How

In the spirit of RV-388, I tried to obtain the Shape object by augmenting the ProofLayout trait. Turns out the serde serialisations do not correspond one-to-one with std::mem::size_of::<T> not even for simple types, forcing me to use the to_merkle_tree method to ensure correctness.

The pros of having a lazy_static

• No runtime overhead (the STATE_SHAPE is only 24 bytes anyway)
• Very easy implementation, leveraging to_merkle_tree which also ensures correspondence between what the generated proof is and the Shape obtained for deserialisation.

The cons of having a lazy_static

• Takes about 30 seconds of compile time when using --features ocaml-api, due to allocating an Owned backend and then transforming it to a ProofGen backend.

Manually testing the MR

cd src/riscv
make all

Benchmarking

Interpreter not impacted.

Regressions

N/A

Tasks for the Author

• Link all Linear issues related to this MR using magic words (e.g. part of, relates to, closes).
• Eliminate dead code and other spurious artefacts introduced in your changes.
• Document new public functions, methods and types.
• Make sure the documentation for updated functions, methods, and types is correct.
• Add tests for bugs that have been fixed.
• Put in reasonable effort to ensure that CI will pass.
  • make -C src/riscv
  • dune build src/lib_riscv
  • dune build src/rust_deps
• Benchmark performance and populate the table above if needed.
• Explain changes to regression test captures when applicable.
• Write commit messages to reflect the changes they're about.
• Self-review your changes to ensure they are high-quality.
• Complete all of the above before assigning this MR to reviewers.