feat(docker tests): add L1 messages to testing

[frisitano]

Overview

This PR introduces anvil state that is configured for testing.
The contract addresses can be found in the .env file. The state must be loaded into anvil using the --load-state argument. The state contains 10 prefunded accounts derived from the mnemonic "test test test test
/// test test test test test test test junk". The first prefunded account (0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266) was used to deploy all scroll contracts and as such, is the owner. The sequencer in the system config contract has been set to the signer address we use in the docker-compose testing stack.

---

L1 message testing uncovered a bunch of issues:

1. bug where only 1 L1 message per block is possible. fixed in this commit. though we should add some test cases for this.
2. the Docker compose test is configured with Anvil as L1 with a block time of 1s and 4 slots per epoch. this means that blocks are finalized after ~8s. however, during testing I ran into a problem that l2geth didn't know some L1 messages (and banned RN peers). this is due to a hardcoded fixed request interval of L1 messages of 10s in l2geth. so this is only an issue for testing but still needs to be fixed. I'll open a PR to add a flag so that we can configure it in the test to 1 or 2 seconds.
3. RN sequencer produced a block with repeated L1 messages.
   a. this seems to be due to a race condition when the payload building job is completed and a new job is already kicked off. ie we call Sequencer::handle_new_payload too late. we would need to process the l1 message counter directly when consuming it (ie in build_payload_attributes). however, I'm not sure this would work in all circumstances. assume we receive a block (sequenced by another node) and simultanously the node also starts sequencing. then the same could happen. to address all cases I think we need to make sure that the latest payload/block is fully processed before building a new payload
   b. another problem uncovered by this: l2geth nodes rejected the block with duplicate L1 messages since L1 messages are not consecutive over block boundaries. however, RN accepted the block. we need to make sure we check not only for messages being consecutive within a block but also across blocks.