Fix: Change VMOperation's op field type to ensure future proof

[mouseless0x]

Version
ethers 1.0.0

Description
The pull request #1858 addressing issue #1857 was implemented using a unstable design pattern that will cause issues in the future. A better approach would be to make the op field in VMOperation of type String instead of the newly introduced enum OpCode.

Making this change solves the following potential issues:

• Different clients labelling the same opcodes differently. (E.g. Opcode 0x20 on Geth is called KECCAK256 whilst opcode 0x20 on erigon use to be called SHA3 until very recently where 0x20 was renamed to KECCAK256)

Warning
Currently, opcode 0x20 on enum ethers::core::types::OpCode is named SHA3 which causes any rpc call with VmTrace enabled on a geth node or updated erigon node to panic as it can't deserialize and map KECCAK256 to SHA3

• If opcodes are added or if existing opcodes are renamed (e.g. eip-4758), ethers::core::types::OpCode will need to be updated to reflect this. Otherwise existing applications will panic whenever a VmTrace is requested as it won't be able to deserialize and parse the new opcodes from the trace.