Analysis of benefits from turning off gas accounting for historical transactions

This is continuation of https://github.com/torquem-ch/silkworm/issues/78

This time, we run a slightly modified version of EVM through the historical transactions. These are the modifications (unless I forgot something):

1. "Out Of Gas" exception is fatal, meaning that it does not just abort the current frame of execution, but fails the entire execution. The transaction that failed in such way, we exclude from consideration for this analysis.
2. EVM stack now has a new type of value, "unknown". This could be implemented by a separate stack of boolean values, for example.
3. Opcode `GAS` pushes "unknown" value onto the stack instead of the current leftover gas (it is supposed to be inaccessible when the gas accounting is turned off).
4. Any arithmetic operation with "unknown" value result in "unknown" value (it is "sticky" in that way)
5. Any `JUMP` or `JUMPI` opcodes that attempt jumping to "unknown" destination, fail the execution (and transaction is excluded from the consideration).
6. Any state reading or writing operations (for example, `SLOAD`, `SSTORE`, `BALANCE`) with "unknown" address fail the execution.

I might have forgotten some other cases where "unknown" value must fail execution, should be added to the list as we proceed with the analysis.

The goal of the analysis is understand how many transactions can execute in exactly the same way as they did, but without EVM performing any gas accounting. Then, construct a data structure that would store "used gas" for each transaction in the past, and use that information to augment the execution without gas accounting, to get exactly the same effect as with the gas accounting. Then, measure potential runtime benefit of such turning off the gas accounting.