op-deployer: create calldata for superchainConfig tx

# Overview

For `op-contracts/v4.x.x` and beyond, the process to change the SuperchainConfig address within the L1 contracts is to create a tx bundle comprised of the following three txs:
1. set SystemConfigImpl to our StorageSetter contract (address `0xd81f43eDBCAcb4c29a9bA38a13Ee5d79278270cC` on mainnet and sepolia)
2. set new SuperchainConfigProxy with `setBytes32` on the slot storing the SuperchainConfigProxy address
* for U16/16a, the 32byte value will only have SuperchainConfigProxy address
* for U17 onward, the 32byte value is packed with SuperchainConfigProxy AND minBaseFee (can be 0 if not set)
4. set SystemConfigImpl address back to original value
To provide a nice UX, op-deployer should be able to produce a single hex string of calldata that represents that entire tx bundle. The final tx containing the bundle should target `MultiDelegatecaller`, which should be called by the proxyAdmin

# Command inputs

This should be a new command `op-deployer manage set-superchain-config` (similar to `op-deployer manage add-game-type`. Inputs to the new command:
* SystemConfig proxy address
* new SuperchainConfigProxy address
* l1ChainId (or l1-rpc-url, from which l1ChainId can be derived)

# Validations

Before outputting the calldata we should have op-deployer run a check that a SuperchainConfig is actually in the storage slot we think (to ensure we're updating the correct slot).

* [storage layout snapshots](https://github.com/ethereum-optimism/optimism/blob/2e0d9ab73c20e881b438ac16d903769f039813b3/packages/contracts-bedrock/snapshots/storageLayout/SystemConfig.json#L121-L134) show we expect the superchainConfig in slot 108
* we can read slot 108, extract the address, and then make a call to a view method that we expect to exist on a superchainConfig, like pauseExpiry() — this will give us confidence we're replacing the correct address
* starting in U17 we have the minBaseFee packed into the same slot