Revisit human-readable presentation of EVM opcodes

[quasiyoke]

During the discussion of pull request #1544, we discussed that the representation of the opcode list in memory may be improved (#1600), and the code displaying opcodes may need refinement #1544 (review)

I prefer a solution like this. It has disadvantages:

1. Requires new dependencies:
   • num-derive — we haven’t used this before.
   • num-traits — we already use this directly.
   • strum — is used in our subdependencies.
2. Will increase build time.

#!/usr/bin/env rust-script
//! ```cargo
//! [dependencies]
//! num-derive = "0.4.2"
//! num-traits = "0.2.19"
//! strum = { version = "0.27.2", features = ["derive"] }
//! ```

use num_derive::FromPrimitive;
use num_traits::FromPrimitive;
use strum::IntoStaticStr;

#[derive(FromPrimitive, IntoStaticStr)]
#[repr(u8)]
enum Opcode {
    Stop = 0,
    Add = 1,
    Mul = 2,
}

fn main() {
    let s: &str = Opcode::from_u8(2).unwrap().into();
    assert_eq!(s, "Mul");
    println!("{}", s);
}

A part of #1560
As a follow up of #1544 (review)

[MOZGIII]

Keep in mind we have to interop with evm::Opcode which we don't own

[quasiyoke]

Via recent TWiR: https://sailor.li/ints-to-enums

TLDR

There're also:

• derive_more::TryFrom — has a more idiomatic interface, is available in derive_more since 1.0.0.
• int_enum — impls TryFrom<repr> as well.

In beta there's std::mem::variant_count.

[MOZGIII]

We would also need to support "other" opcodes - the ones we don't have the names for. Also, from my experience, strum is the to-go solution (other ones are worse one way or another).

[dmitrylavrenov]

Probably, reusing evm::Opcode and applying #1642 should cover our goal ?

@quasiyoke

[quasiyoke]

I underestimated how important future-proof support for “invalid” opcodes might be to us. For this reason, evm::Opcode is simply a wrapper around a u8, allowing for opcodes that are not yet known; so using an enum here would not be straightforward.