feat(testing): Stateful Engine X Format and Fill Transition Tool

Original idea from this comment: https://github.com/ethpandaops/gas-lighting-tracker/issues/34#issuecomment-3841169400

### New `StatefulBlockchainEngineFixture`

Similar to `BlockchainEngineXFixture` where all tests use the same genesis pre-allocation but with the main difference is that the pre-allocation is not included in a JSON file, rather it is a pointer to a stateful snapshot, which is the snapshot that should be used to initialize the client running the tests.

### New `StatefulTransitionTool`

Since the stateful snapshot is extremely big, it will not be possible to use common t8n tools, because these ingest the full pre-allocation via a JSON file, and since this file would be too big to process, it will be inefficient and maybe impossible.

Proposed solution is to create a new `TransitionTool` subclass that uses a fully instantiated client to perform the state transition.

#### Instantiation

The `start_server` method of this new class would reach out to the running client to verify it's running the correct snapshot, and that the client supports the [`testing_buildBlockV1` endpoint](https://github.com/ethereum/execution-apis/pull/747).

#### State transition evaluation

The `evaluate` method of this class would:
- Make sure the client is currently at the desired head for the current request
- Format the input and then perform a `testing_buildBlockV1` call to the client to build a block with the list of transactions it requires to be included.
- Record the output and transform it to the expected response.

#### Parallelism

Since we only have one instance of the client, and the client would need to rollback to a previous state via forkchoice update, it might not be possible to use xdist when filling these tests, but it's an open question.

### Modified Fill Process

Not exhaustive list of requirements:

#### New flag to activate mode

Perhaps we can add a new flag to `fill` to enable this mode, `--stateful`, which requires some other flags to be passed, e.g. the RPC address of the full client running the snapshot, and also a flag that contains the reference to the snapshot (the state root hash perhaps?)

### Other Considerations

Since we are relying on a pre-existing snapshot, we cannot modify the storage pre-allocation (perhaps we can? and produce a snapshot-delta?) the test filler must be modified slightly to do the `pre.deploy_contract`, `pre.fund_eoa`, etc., in blocks on top of the snapshot, and then run the test blocks on top of these "setup blocks".

We also can take special care of using stubs during filling too in order to replace `pre.deploy_contract` with contracts we are sure exist in the snapshot.