OPCM and `ProtocolVersions`

As of today, we have stopped using the `ProtocolVersions` contract due to it being too much of an overhead to keep up to date. It could be worth simplifying the way that it is used and integrating into OPCM, to guarantee safety over liveness universally (ie prevent syncing the wrong chain with outdated client software)

Think of the `ProtocolVersions.required` field as being a synchronization between the L1 contracts and the client software. OPCM would call `ProtocolVersions` and be able to modify the `required` field.

One possible way to manage the versioning: if the L2 client software absolutely will not work with the L1 contracts, we should bump the major version. We could bump the minor/patch versions on other upgrades where the client software doesn't absolutely need to be updated. The L2 client software would have a max known major version and compare it against what is onchain and halt if the onchain version is greater than the known version.

We could delete/simplify parts of `ProtocolVersions` so that it exactly fits the usecase of universally guaranteeing safety over liveness. With this universal guarantee, then we no longer need to make decisions like the derivation pipeline halting on unknown `ConfigUpdate` event types, it could just ignore them. This will help to decouple the ability to upgrade L1 contracts and L2 client software independently, with an explicit onchain synchronization mechanism.

No files or tests are named. Start by tracing how ProtocolVersions.required relates to the L1 contracts, OPCM, and L2 client software, then review the derivation pipeline's handling of unknown ConfigUpdate events. Done means an agreed, documented versioning and synchronization design that guarantees safety over liveness.

Written by the indexing model from the issue text.