feat(op-proposer): support creating ZKDisputeGame

[welkin22]

Description

When we use ZK fault proof, we need the op-proposer component to adapt to the new process, submit ZKDisputeGame to the disputeGameFactory, and thereby submit the outputRoot to the L1 chain.

Rationale

When the relevant flag is configured, the process of submitting a new ZKDisputeGame will begin. This process will first find the appropriate parent game through the disputeGameFactory contract, then obtain a sufficient number of outputRoots, construct the corresponding data, and call the createZkFaultDisputeGame method of the disputeGameFactory contract to create a new ZKDisputeGame.

Example

To start a new process for submitting ZKDisputeGame, the following configuration is required:

--game-factory-address="0x..."
--anchor-state-registry-address="0x..."
--game-type=3

We have some optional configurations:
--zk-proposal-batch-size: controls the number of blocks covered by a game, default value is 3,600
--zk-proposal-step-size: controls the block height interval between obtaining two outputRoots, the default value is 3
--zk-proposal-parent-game-address: we can specify the address of the parent game, forcing the op-proposer to use it to continue creating sub-games after startup.
--zk-proposal-last-game-cache-path: we can specify the address of a cache file, so that when the op-proposer restarts, it can read the cache file to continue creating sub-games from the last submitted game before the restart.

Changes

Notable changes:

• Added some flags
• Some modifications to L2OutputSubmitter to support the submission logic related to ZKDisputeGame
• LastGamePersistenceCache to support caching the last submitted game data
• OutputRootCacheHandler is used to batch retrieve outputRoot.