Support for multiple evmc vm's.

[aarlt]

• work in progress
• still incomplete, hacky & unoptimized, but probably the basic idea is already visible
• introduction of EVMHosts, that inherits from EVMHost.. EVMHosts is now used within ExecutionFramework, the different evm vms will be initialized via the command line option--evmc
• current idea is basically to distinguish between creation & normal calls to the evmc vms
• based on the capability of the evm, "evm" or "ewasm" bytecode is deployed to the evmc vm
• normal calls e.g. sendMessage(..) will basically iterate through the defined evms and call "sendMessage" per instance.. results will be collected and compared if they are the same
• if they are the same some members of EVMHosts will be set, so that e.g. SolidityEndToEndTests.cpp can still operate on the defined member variables, if they where not the same, an assertion will fail
• created a fake-ewasm branch of evmone here https://github.com/aarlt/evmone/tree/fake-ewasm, this special evmone will basically just set the ewasm capability flag
• right now no contract is compiled to ewasm, instead the bytecode for ewasm is just evm bytecode, appended with some additional bytes fake-ewasm.. I did this to be able to test the "deployment-behaviour" before hera supports evmc v7

[axic]

I would suggest this refactoring PR only makes support for multiple EVMC VMs, but only keeps evmone. Then separately we can introduce hera and running ewasm tests.

[axic]

Also hera 0.2.5 is not evmc7 compatible, 0.2.6 will be :)

[aarlt]

ah yes, I know.. I just wanted to have the hera things similar to the evmone things.. but I where also thinking to not introduce any hera specific code.. right now additional evmc vms can be defined by setting --evmc <path-to-a-evmc-library>, potentially multiple times

[chriseth]

I don't think we should implement this kind of "Y"-connector. We should handle wasm in a similar way as we handle compileViaYul. The host just receives a VM and does its thing - it should not care about what that VM really is.

[aarlt]

Replaced by #9143.