EVM: produce transaction receipts

Context

Closes #4955 (closed) Closes #4956 (closed)

Based on !8029 (merged)

This writes transaction receipts fields to transactions_receipts/<tx_hash>/..:

> show subkeys /transactions_receipts/00c53832926fc00b69a2287ad988f2d7b5fecf9da44b2218a40d04d13c5fe277
/block_hash
/block_number
/from
/hash
/index
/status
/to
/type

This is now used by the proxy server to return real values to eth-cli. Note that I did not implement getTransactionByHash because eth transaction:send waits for the transaction to be mined to terminate, that is, it needs to have a receipt. So if eth transaction:send the transaction has a receipt.

Manually testing the MR

Here we go (test on mondaynet):

# Run a node
./octez-node config init --network=https://teztnets.xyz/mondaynet-2023-03-13 --data-dir ~/.octez-node-mondaynet 
./octez-node run --rpc-addr localhost:8732 --data-dir ~/.octez-node-mondaynet
# Compile the kernel
make -f kernels.mk build-kernels 
# Use the kernel installer to have an origination-ready kernel
src/kernel_sdk/target/release/smart-rollup-installer get-reveal-installer --upgrade-to evm_kernel.wasm --output installer.hex --preimages-dir /tmp/installer
# Originate the rollup (and get the rollup address)
kernel=$(cat installer.hex)
./octez-client originate smart rollup from <tz1> \                            
  of kind wasm_2_0_0 \
  of type bytes \
  with kernel $kernel \
  --burn-cap 999
# Run a smart-rollup-node
./octez-smart-rollup-node-alpha --base-dir ~/.tezos-client init batcher config for <rollup-address> with operators <tz1> --data-dir ~/.octez-rollup-node-mondaynet
mv /tmp/installer /home/valentin/.octez-rollup-node-mondaynet/wasm_2_0_0/
./octez-smart-rollup-node-alpha --base-dir ~/.tezos-client run --data-dir ~/.octez-rollup-node-mondaynet --rpc-addr 127.0.0.1 --rpc-port 8888
# Run an EVM Proxy server
./octez-evm-proxy-server run --rollup-node-endpoint http://localhost:8888    
# Finally, play with MetaMask :)

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR