Easy to convert test from ethereum/tests  #1505

Following are the tests that are relatively easy to convert while also allowing to convert a large number of files from the tests repo in one go:

Random tests

stRandom
stRandom2
In random tests need to look at the vm trace. Really are triggered like 5-6 cases of vm exceptions
I think it is enough to create minimum set of instructions that trigger the same vm exception. 1 per test.
Many tests just repeat itself.

Zero knowledge

stZeroKnowledge
stZeroKnowledge2
Most tests from this folders are really just vectors for the precompiles. It is a base template with many parametrisation vectors.

Precompiled contracts

stPreCompiledContracts1
stPreCompiledContracts2
This are basically vectors to test the precompiles. should be easy to convert.

Quadratic complexity folder

stQuadraticComplexityTest
This must be not really quadratic complexity but the stress tests that call something many times. Easy to convert.

Storage overwrite combinations

stSStoreTest
This tests mainly verify the gas usage of storage touch situations x to 0, 0 to x, x to x, 0 to 0 and so on.
And refunds to when we x to 0, or 0 to x to 0.
This can be extended to also verify tstore in the same manner.

TimeConsuming tests

stTimeConsuming
Need to revisit this test logic, but as far as I remember that are basically also storage overwrite/refund combinations.
It is one template with many-many-many vector combinations. can really shrink down in python in code.

stWalletTest

stWalletTest
This are legacy tests. those are actually ever first DAO tests if I am not mistaken. this does not test much of evm, but a smart contract. we can decide if we want to drop it or keep it. can be just converted as is. but sometimes I saw this tests breaking with the protocol development, so maybe they have something.

Call Combinations Interuptions

stCallCodes
stCallDelegateCodesCallCodeHomestead
stCallDelegateCodesHomestead

Here all tests are basically the same template. we take [calltype] -> C1 -> [calltype2] -> C2 -> [calltype3] -> C3
where calltype are all possible call opcodes. and C1, C2, C3 contracts are recording the context opcodes results like origin, selfbalance, address and so on. then at some point can happen a revert by REVERT, OOG, and this revert can happen at C1 or C2 or C3 so really here are just

for all calltypes
for all oogtypes
for all oogposition
[calltype] -> C1 -> [calltype2] -> C2 -> [calltype3] -> C3

the type of call changes the result of context opcodes. and reverts are removing the subcall changes. so it creates interesting situations where we can see what are the values of context opcodes, which contract they are recorded to and was it really reverted when OOG* happened.

Gas Prices

stEIP150singleCodeGasPrices
Here I have some ideas. this a basic test to measure gas price of some atomic evm operations. what we really need is to have a gas schedule map in python defined for each fork. and then we test on each fork that that schedule is really what external evm charges.

by schedule I mean. intrinsic transaction gas, intrinsic call operation gas, storage access gas, hot address / call address call, base opcode gas price (I think already covered but without the schedule), memory expansion gas price formulas and so on. so here a little more work.