Introduce transient storage support for inline assembly

[matheusaaguiar]

This PR introduces basic support for the transient storage opcodes TSTORE and TLOAD for inline assembly only.
Based on previous groundwork by @hrkrshnn (Thank you 🙏).
Part of #14739

[ekpyron]

This will need as separate key-value store in m_state, i.e. you'll need to add
std::map<util::h256, util::h256> triansientStorage; to InterpreterState. Also a quick look at whether we do anything specially for InterpreterState::storage would be good (e.g. if we reset it somewhere). Eventually for actual fuzzing/tracing, we will need an analog of InterpreterState::dumpStorage(std::ostream& _out) const; as well, but we can add that in a separate PR with fuzzing support for transient storage (@bshastry may want to get to that eventually - in that PR we can also check if we need to do anything further to account for the special lifetime of transient storage in the fuzzing setup)

[ekpyron]

I just had another quick look through this, and we should still really have some semantics tests for this.

The easiest one would be a simple reentrancy lock, so something like:

contract C {
  modifier nonreentrant {
    assembly {
      if tload(0) { revert(0, 0) }
      tstore(0, 1)
    }
    _;
   assembly {
      tstore(0, 0)
   }
  }
  function f(bool simulateReentrancy) nonreentrant public {
    if (simulateReentrancy) {
       f(false);
    }
  }
}
// ----
// f(bool): false ->
// f(bool): true -> FAILURE

For more complex cases, like testing the behaviour across multiple transactions, we'd actually need to see how evmone handles this right now. So I'm actually not sure what the following test would do currently:

contract C {
   function f() external { assembly { tstore(0, 42) } }
   function g() external returns(uint r) { assembly { r := tload(0) } }
}
// ----
// f() ->
// g() -> which is it, 0 or 42? depends on whether evmone and the way we call this consider these calls separate transactions

Also a few of other sanity tests (showing collision-freeness with memory and storage and such) may be nice.
I mean, we're more testing evmone here than us, but still we should have these tests to see if anything breaks (it could also be us assigning incorrect opcode values or such, e.g. by accident swapping tstore and tload - or not accounting for an opcode reassignment since Hari's draft etc)

tstore(0, 21)
mstore(0, 42)
sstore(0, 42)
if iszero(eq(tload(0), 21)) {
  revert(0, 0)
}

[nikola-matic]

This is gonna needs docs and a Changelog entry as well.

[cameel]

I rebased the PR on develop and added a fixup with some smaller tweaks that weren't worth a comment.

[cameel]

Looks like #14737 (comment) and #14737 (comment) are the only remaining things here. Once those are taken care of I'm going to approve it.

[nikola-matic]

There are a few optimizer tests missing, but otherwise looks good.

[cameel]

I just merged MCOPY PR so this needs conflict resolutions.

[matheusaaguiar]

Rebased and squashed commits.

[cameel]

ok, looks like we're done here. Please squash and we can merge.