feat(fill,benchmark): add new contract-only fixture format for spamoor

Add a new JSON fixture format that gives easy access to benchmark contracts for tools such as [spamoor](https://github.com/ethpandaops/spamoor). This should be a minimal format and only include the contracts required by the benchmark test so they can be deployed and called on testnets/devnets.

@pk910 mentioned that this could be enough to be useful:

```json
{
"tests/zkevm/test_worst_compute.py::test_worst_binop_simple[fork_Cancun-blockchain_test-opcode_ADD-]": {
"code": "",
"network": "Cancun",
"_info": {
"hash": "0xe0c586ab957c35b38569460c66c3cce60e0462008110477e6f9522c2b4a67edb",
"comment": "`execution-spec-tests` generated test",
"description": "Test running a block with as many binary instructions (takes two args, produces one value)\n as possible. The execution starts with two initial values on the stack, and the stack is\n balanced by the DUP2 instruction.",
"url": "https://github.com/ethereum/execution-spec-tests/blob/zkevm@v0.1.0/tests/zkevm/test_worst_compute.py#L549",
"fixture-format": "benchmark_contract"
},
...
}
```

It's worth considering the following:
- [ ] Should we include any relevant transaction deployment information?
- [ ] For call and create contexts, more contracts are required? Can/should we label the contracts?

...but worth discussing with @pk910 before creating a solution he might not need, pk wrote:
> I can handle tests that involve multiple contracts too.
> I had a similar situation with the nethermind benchmarks, they usually have 2 contracts and the address of the 2nd is statically baked into the first. I'm basically just replacing the address within the bytecode there. But would need to original addresses too to do this, so I can search for that address in other bytecodes.