fix(vm): Bytecode comparison

[marioevz]

🗒️ Description

Fixes Bytecode equality comparison method to take other properties into account when comparing against some other Bytecode object.

The issue surfaced when I tried to implement tests for EIP-5920 that contains the PAY opcode, which collides with the EXTDELEGATECALL opcode for EOF. When both opcodes were included in the same Enum, it seems like this class internally performs an optimization that compares all items and reuses instances that return __eq__() == True, which lead to the Op.PAY being equal to the value assigned to Op.EXTDELEGATECALL.

🔗 Related Issues

None.

✅ Checklist

• All: Set appropriate labels for the changes.
• All: Considered squashing commits to improve commit history.
• All: Added an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• Tests: All converted JSON/YML tests from ethereum/tests have been added to converted-ethereum-tests.txt.
• Tests: A PR with removal of converted JSON/YML tests from ethereum/tests have been opened.
• Tests: Included the type and version of evm t8n tool used to locally execute test cases: e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
• Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.

[winsvega]

i think this must be enough. because pushed popped is our own construct.
I use opcode generation from int number. and I don't provide the poped or pushed values.

so for such dynamically generated opcodes. lets say I want opcode(x) where x is 0.255
this comparison won't work

[marioevz]

It's used in EOF for example, the same binary bytecode can have different max_stack_height in two different sections:

Section.Code(Op.RETF, inputs=1)

has not the same max_stack_height as:

Section.Code(Op.RETF, inputs=2)

so I think it might be worth it to differentiate between two bytecode objects if we have these properties available.