Interop: Cross Chain Message Throttling

Every executing message that is included adds cost to the derivation pipeline. There needs to be some mechanism by which that cost is paid for by users. There are a few options here:
- Enforce in the `CrossL2Inbox` a max number of executing messages per block. This would need to be coupled with a rule that marks reverting executing messages as resolved automatically instead of needing to fetch data from remote chains to resolve the executing messages. This can greatly reduce the cost in the derivation pipeline but adds a requirement of L2 receipt fetching from within derivation
- Enforce in consensus a max number of executing messages per block. Any block with more than a certain number of executing messages is considered invalid and skipped. This means that a hardfork is required to change this value unless we decide to add it to the L1 attributes transaction so that it can be dynamically changed by the chain operator
- Burn gas in the `CrossL2Inbox` to artificially make it more expensive to send cross chain messages. Ideally we avoid a concept of an EIP-1559 like curve with a supply/demand curve and basefee because that is complex to test. We can burn a flat amount per message. Any sort of dynamic amount of gas burned will result in gas estimation issues
- Accept fee payments in ether in the `CrossL2Inbox` instead of burning gas. This is a better throttling mechanism than burning gas although we do not have any prior art for this kind of design