Connect eip1193 with MetaMask

[SebastienGllmt]

for the eip1193 wrapper in paima-rest, we currently don't support actually connecting this to MetaMask, but this would be really nice to have

To do this, we need to at least

1. Fix eth_chainId. Right now it returns the chain ID of the main chain, but this isn't right because this would make it clash in MetaMask with the real chain (i.e. each game need to have a separate "id"). This is a bit awkward since it forces us to create a new standard for what "chainId" means for Paima games. We previously used things like the L2 contract address and the "game name", but neither of these are usable as an int like chainId requires. Probably the steps for this are
   1. Properly decide what the "chainId" is for Paima apps (probably some combination of the main chain ID + the game name. We shouldn't use the L2 contract address when possible since it's not guaranteed to exist for every Paima dApp. For example, if Avail is the main chain, there is no L2 contract address since it's replaced with an Avail app ID instead)
   2. Get a number by running it through a hash function (maybe a 64-bit version of fnv32a). Obviously this means there will be some collisions because chainId is only around 64 bits at most, but that's okay.
2. Fix eth_getBalance. This can be implemented in two ways I think:
   1. Do something like the achievement system where we users can, in their code, specify the endpoint logic for how to fetch this data
   2. Define some kind of token standard for Paima (this might be better if we want to properly render tokens in explorers). Note: there is a question of how MetaMask handles ERC1155/ERC721/ERC20 if the user manually adds it by contract address. Not sure if there is a good way to support this without a lot of extra work
3. (low priority) Fix eth_sendRawTransaction. This is a lower priority because in a lot of cases for games you don't even want to allow people to freely send tokens (we would have to figure out how to get failed txs to appear in MetaMask. Doavle in theory). Probably this would have to be implemented by having an easy way to define a way to convert an Ethereum signed message to an STF input, but this is a bit complex and we're going to change the STF system soon anyway, so it's lower priority