Make list of opcodes property of VM instance

[s1na]

Fixes #591, also related to #543

Instead of having a global list of opcodes in the opcodes.ts file, this PR sets this list as a property of the VM instance to avoid problems when two VM instances with different HFs are created.

I also made each opcode to be an object instead of a list. Objects are typed easily and are more flexible.

Note: If the Common instance of a VM instance is modified after construction, the list of opcodes will be out-dated.

[holgerd77]

Shouldn't _opcode rather be a property of the EVM instead of the VM? In the current implementation this is referencing back and forth between Interpreter and the VM object, introducing a new circular dependency.

[s1na]

Shouldn't _opcode rather be a property of the EVM instead of the VM? In the current implementation this is referencing back and forth between Interpreter and the VM object, introducing a new circular dependency.

So it's possible to have the list of opcodes as a property of Interpreter, EVM or the VM. I don't have a strong preference here and will do as you think best.

The good thing about VM is that the list of opcodes doesn't need to be instantiated when running every tx (but this shouldn't be a expensive operation, so it's okay), and users could pass a list of modified opcodes to the VM. Between EVM and Interpreter I'm slightly in favor of Interpreter, because if it was stored in EVM we'd again need a circular dependency, whereas Interpreter has directly access to Common and could detect the HF and set the list.

[coveralls]

Coverage decreased (-0.1%) to 95.278% when pulling 4ce3b7a on hf-opcodes-in-vm into 9333e02 on master.

[holgerd77]

Ok, let's leave this "as is" for now - see there are good arguments in both directions. As long as we still have EVM and VM this tightly coupled this will do the job and if we decouple we'll likely have to do some further refactoring anyhow.

Will approve now.