Add configurable-sized contract templates to use with EELS

[jochem-brouwer]

Adds the templates which EELS introduced but which (size parameters) are missing here:

            case AccountMode.EXISTING_CONTRACT_MINIMAL:
                return MinimalContractInitcode()
            case AccountMode.EXISTING_CONTRACT_SAME_MAX:
                return StopJumpdestInitcode(
                    code_size=self.code_size, diff=False
                )
            case AccountMode.EXISTING_CONTRACT_DIFF_MAX:
                return StopJumpdestInitcode(
                    code_size=self.code_size, diff=True
                )
            case AccountMode.EXISTING_CONTRACT_JUMPDEST:
                return JochemnetPredeployContractInitcode(
                    code_size=self.code_size
                )

(ref: https://github.com/ethereum/execution-specs/blob/5fa5938b1ce01c661b3e9beaa403e4edddd11e1a/tests/benchmark/helper/account_creator.py#L303-L316)

In particular, the code size of the template can now be edited. Supports up to ~16MiB of contract size.

EELS might need: jochem-brouwer/execution-specs#4

[CPerezz]

None of the templates were added to the CI to be tested.

See docs/SKILL.md:

"add a covering entity to examples/full-matrix-spec-feature.yaml so CI exercises it."

Other stale docs after the additions:

• internal/specbuild/full_matrix_test.go:32 — entity count pinned at 29
• docs/SKILL.md — "29-entity" appears three times (frontmatter description, "Read these first", "Canonical spec reference")

Also, can we please remove drastically the verbosity of the comments? It's a lot of LOC just wasted in AI slop. Not really adding a ton of value.

Another note, for unique_jumpdest, the entry JUMP targets code_size - 1. JUMPDEST validity requires the target not be push-data, but the embedded address bytes at 0x2C..0x40 are decoded as opcodes during analysis, and an address byte that happens to be a PUSHn swallows up to 32 following bytes.
At code_size: 0x41 the target (0x40) sits immediately after the address, so for a large fraction of derived addresses the entry jump is invalid and any CALL exceptionally halts.

[CPerezz]

Upstream EELS emits PUSH1 where this code emits PUSH2

So the pinned hashes for 0x41 and 0x100 in this test cannot be reproduced from an upstream checkout today, despite the test comment's "Regenerate from an execution-specs checkout" instructions.

Sizes in (0x100, 0x1000000] happen to agree because minimal and fixed widths coincide there; max_same/max_diff match upstream master at all in-range sizes already, since StopJumpdestInitcode has no jump target.)

[CPerezz]

"Both create2_deploys and create_preimage_deploys accept an optional code_pattern:" — it's three templates now.

[jochem-brouwer]

Another note, for unique_jumpdest, the entry JUMP targets code_size - 1. JUMPDEST validity requires the target not be push-data, but the embedded address bytes at 0x2C..0x40 are decoded as opcodes during analysis, and an address byte that happens to be a PUSHn swallows up to 32 following bytes.
At code_size: 0x41 the target (0x40) sits immediately after the address, so for a large fraction of derived addresses the entry jump is invalid and any CALL exceptionally halts.

I have to verify this, the address encoded here starts at 0x2C (44), and is 20 bytes, so it might seem like it runs to byte 64 (0x40), but this is not the case: bytes 44-63 are covered with the address, if we would also have byte 64 then this address would be 21 bytes long. So I don't think this is the case.

Regarding PUSH1/PUSH2, we should ensure the produced code matches whatever a live network produces, so will fix this. We could also just ban sizes below 256, I think the interesting use cases are the Osaka size, the Amsterdam size, the empty contract, and maybe small unique contracts (64 bytes).

Thanks for the review @CPerezz 😄 👍

Will address ASAP.