ISemver policy

[JosepBove]

This issue stems from a discussion with @maurelian about whether RISC-V.sol should implement the ISemver interface and the need to clarify and potentially standardize our policy on the use of ISemver across contracts.

The file RISC-V.sol is currently vendored and does not inherit from ISemver. This might be due to its origin as a copy-paste from another repository where ISemver does not exist. While its inclusion could improve consistency, this raises questions about our general approach to vendor contracts and ISemver.

In our discussion, we also noted that ISemver is primarily used to enforce implementation of versioning. However, this practice might be inconsistent with other parts of the codebase.

Questions that raised:

• Should all on-chain contracts, including vendor contracts like RISC-V.sol, implement ISemver?
• Should we enforce the ISemver interface only through checks rather than inheritance, especially for vendor contracts?

[maurelian]

If there was only one actionable thing to come out of this, it would be adding a semgrep check to ensure onchain contracts conform to some standard.

[tynes]

• RISCV.sol should implement ISemver. Its vendored from asterisc because we don't know how to work without a monorepo. https://github.com/ethereum-optimism/asterisc
• Why would RISCV.sol inherit ISystemConfig? You left out context here. Do you mean IRISCV.sol? If so, @smartcontracts @mds1 are the decision makers here. I am of the opinion yes, because it will make writing assertions easier and have less of an impact on compile times (just import the interface rather than the impl to make the calls)
• What is the benefit of not inheriting ISemver? Seems like extra tooling requirement that we need to maintain rather than just using the compiler itself