Implement relay decision sidecar

[cam-schultz]

Context and scope
See #276

Discussion and alternatives
Here's one possible strategy for implementing the sidecar:

1. Modify teleporter.messageHandler.ShouldSendMessage to dispatch the TeleporterMessage to the sidecar process, duplicating the existing decision logic. The gRPC interface only needs the TeleporterMessage itself; all other parameters are provided via independent configuration to the sidecar.
2. Explore passing the vms.DestinationClient over gRPC so that the sidecar can re-use the main relayer process' configuration.
3. Explore the possibility of implementing MessageHandler as a gRPC client

Depending on the volume of the changes involved, it might make the most sense to split this into multiple tickets, and mark this one as completed partway through the above list.

Open questions

• Depending on how far along the three steps outlined above we get, we need to decide how the configuration and MessageHandler types will be structured. Specifically, we could define the sidecar as it's own "message protocol", so that the MessageHandlerFactories create instances of the sidecar client directly. Or, we could define the sidecar as configuration option within the teleporter package's MessageHandler implementation. The former idea seems like it would be 1) less coupled to any specific protocol and therefore 2) more maintainable, but the interfaces might be tricky to get right. We'd also need to make sure the relayer can still handle MessageHandler implementations within its own process (e.g. the existing teleporter package).
• How should the awm-relayer repo be structured? One possibility is to maintain an example sidecar that implements some basic decision logic for demonstration and CI purposes.

[cam-schultz]

Closing in favor of #362