Use Map for OpcodeList and opcode handlers

[ryanio]

This PR targets resolving the following from #775:

• The opcodes handlers map is indexed by string, it should be done by number.
• The opcodes handlers map and the opcodes OpcodeList's one, should probably be Maps. The semantic of Map is way simpler than an accessing an object with object[key].

[codecov]

Codecov Report

Merging #852 into master will increase coverage by 0.10%.
The diff coverage is 96.40%.

Flag	Coverage Δ
#account	92.85% <ø> (ø)
#block	77.37% <ø> (-0.04%)	⬇️
#blockchain	81.10% <ø> (+0.30%)	⬆️
#common	94.73% <ø> (+0.15%)	⬆️
#ethash	83.33% <ø> (+1.11%)	⬆️
#tx	93.98% <ø> (-0.14%)	⬇️
#vm	82.32% <96.40%> (+0.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[alcuadrado]

I have another idea of how this can be optimized. I built a small script simulating the current implementation, and this other idea, but somehow lost it 😅

I spent some time reading about how to create an efficient jump table in js, and apparently the best way of doing it is with an array. Something important is that we shouldn't leave empty indexes. Instead, an invalid/missing-opcode should be used. This way v8 will, hopefully, optimize it.

Another important thing can be to stop creating opcodes per hardfork, and put the HF validation logic inside each opcode. This way we can use a static array of ocpdes, increasing the chances of this getting optimized.

[jochem-brouwer]

I don't think we should go back to the point where we validate if an Op can be ran inside the Op itself. We can create multiple static arrays, where each array would be the array which holds the Ops of a certain HF. While checking HFs should not take a lot of time, I don't think we should check those at runtime but do that in the initialization phase.

[evertonfraga]

That's great!

Now, I guess the only thing is to decide along with @alcuadrado what route to take wrt Map vs. Arrays.

[evertonfraga]

What is this change about?

[evertonfraga]

Oh! got it. After a more thorough review, I found that the diff has drifted a some lines. All good

[evertonfraga]

👍

[ryanio]

thanks for the review @evertonfraga :) @alcuadrado said we can merge this for now since it's already an improvement, and do a follow-up PR for the array optimization.

i just had to resolve a merge conflict, but should be ready for a final approve and merge now.