Split out Wormhole relayer

[area]

With the current multichain functionality, we focussed on the contracts and not on the additional infrastructure around it. This PR is intended to at least create the scaffolding for that infrastructure, which we can hopefully build on.

As it stands, the mockBridgeMonitor script represents three components of the Wormhole system:

1. The Guardian Network - these are the trusted 'oracles' of the network, who sign attestations that messages have been emitted on a particular chain
2. The Spy - this is something that monitors the guardian network for messages of interest
3. The Relayer - this is something that listens for messages from the spy and relays them to the other chain(s)

We certainly aren't going to be responsible for the Guardian Network. We might end up running our own spy. However, we will certainly need our own relayer to deliver the desired experience for people - they sign a message on one chain and it appears on the other chain, with no further interaction from them. This ends up very similar to the Metatransaction Broadcaster - they execute a transaction that emits an event on one chain, and the relayer ends up executing a transaction on the other chain, paying for gas.

This PR splits out the relayer from the mockBridgeMonitor script, and has it running in a separate process, communicating with the spy via the protocol that it would use in a real deployment. This give us a platform to build a robust relayer on as we go forward. The relayer is extremely simple at the moment. One thing that we had avoided doing 'properly' previously was considering VAAs, but given the libraries being used expect to see VAAs at various points, I've had to do those much more 'properly'.

Some of the changes here we just... stumbled across being necessary. Changing providers to use RetryProvider where I could is certainly something that coul be in a separate PR (and will move if desired), but splitting this relayer out made us more sensitive to connection errors during builds, somehow? We also started to reliably run across issues with hardhat's memory usage during the cross-chain tests, which we've avoided for now by deleting the build-info between the two sets of tests. It feels like that's not going to be able to be a long-term solution, but it's what we've got for now.

There's a lot here, so keen to answer questions and get this in to a mergeable (and understandable) state.

[kronosapiens]

Nice. Why write it in typescript? Was it needed to use the libraries, or just a good opportunity to try it out?

[area]

Nice. Why write it in typescript? Was it needed to use the libraries, or just a good opportunity to try it out?

It wasn't needed, but was certainly helpful for some of this. I also think it's just better for things being deployed to production.

[area]

We also started to reliably run across issues with hardhat's NomicFoundation/hardhat#3471 during the cross-chain tests, which we've avoided for now by deleting the build-info between the two sets of tests. It feels like that's not going to be able to be a long-term solution, but it's what we've got for now.

With these last changes, we've started running in to this even for the first run of the tests, so deleting the build-info was no longer sufficient. I don't like it, but I've upped the resource class for the coverage-test-bridging job to large, which has resolved the issue.

[kronosapiens]

Looks pretty good! A few minor comments.