Suppport CALL-like opcodes

[4000D]

CALL, DELEGATECALL, STATICCALL opcodes should be handled in EVMRuntimeStorage contract.

Rather than verifying CALL along with whole executions in callee contract, just we have to verify that callee contract's state is correctly loaded when evm call depth increased. Then all executions in that call depth can be verified as other opcodes (sload, mload, push, pop, etc).

To summarize, we have to verify 1) when CALL, DELEGATECALL, STATICCALL is invoked, check callee contract's state 2) when executions in callee contract is over (meaning STOP or RETURN invoked), check caller contract's EVM state.

This includes #4

[Jake-Song]

i think we have to consider callee contract's state after executions in callee contract is over.

assuming we have stateRoot, which should be intermediateStateRoot as i mentioned #4 , and Operator and Challenger have different afterStateRoot. and then we can submit beforeStateRoot and do verification game. when executions in callee contract is over (meaning STOP or RETURN invoked), check caller contract's EVM state, but find no differences between them.

So Operator and Challenger have different afterStateRoot but we can't judge who's wrong only if check callee contract's state.

So we need to include callee contract's states in Execution State after CALL and we have to verify callee contract's states. Because Operator and Challenger have a different afterStateRoot, we can't use a proof of inclusion. we have to play verification game for callee contract.

[4000D]

I omitted this meaning, "intermediateRoot in "caller contract's EVM state" will also includes callee's state".

If we track "how intermediateRoot are changed each SSTORE", then it is enough to check intermediateRoot to verify callee's state and executions in callee, in query-resnpond stage.