RISC-V/PROTO: RISC-V PVM Conversions for input, output, input_request

Closes RV-393

What

Adds conversion functions in the protocol implementation of RISCV PVM for input, input_request and output types. These types have a definition in the protocol but they also have a distinct (but similar) definition in the protocol environment.

Note: This MR sets the expected types of Riscv.input_request, Riscv.output & Riscv.input - which contains the type Riscv.reveal_data. Coordination with the implementation of the reveal support is needed here to ensure types will match.

Why

Remove stubs from the protocol implementation of the RISC-V PVM.

How

Two way conversions aren't needed. Turns out only one way conversions are needed when implementing the required interface sc_rollup_PVM_sig.

• input_request: From environment type to protocol type.
• input: From protocol type to environment type.
• output: From environment type to protocol type.

Manually Testing

the riscv regression tests will validate these changes once !16163 (merged) gets merged

# Building
make build -C src/riscv build
make octez-layer1
# Riscv tests
dune exec tezt/tests/main.exe -- riscv

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.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).