StackExecutor inner refactor

[tgmichel]

Draft, for @sorpaas review.

Motivation

Current design provides one entry point per context type - transact_create, transact_create2, transact_call - that trigger the recursive execution of all opcodes in the Runtime to finally capture the ExitReason.

This works but does not allow stepping the EVM. To enable tracing, we need some sort of interface that allows capturing the state between opcode executions. There is currently another proposal from @nanocryk (imo better one, the only one until now that is purely readonly), this is just an alternative approach so we can evaluate the pros and cons of each one.

This PR proposes decoupling call_inner and create_inner in 2 public (prepare, capture) and 1 private (execute) methods.

Performance penalty

Overhead of two additional function calls per call stack.

Visibility concerns

This approach modifies the public Api, and there is no guard to guarantee that for example only call_prepare is called, with no subsequent calls to call_execute and call_capture are made.

Changes

[pub] call_prepare, create_prepare

The initial gasometer corrections, balance checks, nonce handling, etc

[priv] call_execute, create_execute

Create Runtime instance and trigger the recursive opcode execution.

[pub] call_capture, create_capture

Captures the ExitReason.

[sorpaas]

Is it possible to make create_prepare and call_prepare take only &self and not mut?

[tgmichel]

Unfortunately no, they both need mutable access to the state and metadata.