Investigate overhead of asynchronous state access

For better performance in things like `eth_call` in [SilkRPC](https://github.com/torquem-ch/silkrpc) it makes sense to have asynchronous API in `silkworm::State` (SilkRPC uses [Boost.Asio](https://www.boost.org/doc/libs/1_77_0/doc/html/boost_asio.html) coroutines and the state in question is in a remote DB). But async APIs are contagious and making `silkworm::State` use coroutines means that we'll have to use them in [EVMC](https://github.com/ethereum/evmc), [evmone](https://github.com/ethereum/evmone), and Silkworm execution itself. That's the route taken by [Akula](https://github.com/akula-bft/akula).

The goal of this experiment is to assess performance overhead of (probably Boost.Asio) coroutines on the staged sync execution (where we don't really need async API). So the task is to fork EVMC, evmone, and Silkworm, switch them to async API with coroutines (C++20 is a prerequisite), and check what's the slowdown (if any) of the execution stage.

P.S. There's a [plan](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0592r4.html) for coroutine library support, executors, and networking in C++23. Let's hope it materializes, but right now we can play with Boost.Asio.