Relay monitoring & preventing continued relay errors

Once a proposer calls `submitBlindedBlock` to a relay (with a signed header), it depends on the relay to release the block to be able to propose anything (no fallback to a local block is possible at that point due to possible slashing).

There's several relay error scenarios:
1. payload withholding (relay doesn't release the payload and the proposer needs to forfeit the slot)
2. incorrect payload
a. incorrect value (the final amount paid by the builder to the proposer was different to the amount claimed in the `BuilderBid`)
b. invalid block (invalid data / fields)

Question: How can we shield proposers from faulty relays, and how to prevent continuous slots with errors due to faulty relay behaviour?

A possible solution is a monitoring service run by a trusted third-party, which we can call **Relay Monitor** (RM).

1. Whenever mev-boost calls `submitBlindedBlock` to a relay, it also sends a request to the RM, including the `SignedBuilderBid`, the relay it originated from, and the `submitBlindedBlock` body.
2. The RM will also request the payload from the relay
3. Thus the RM can check
a. whether the payload is withheld
b. whether the block matches the bid

If there is any problem, the relay's scoring/reputation is be updated in the RM, and propagated to all connected proposers (by mev-boost polling the relay status endpoint, maybe also push as an option). If any relay behaves incorrectly, all connected proposers can ignore faulty relays for some time. (reputation mechanism TBD).

This (centralised) service can be put into production quickly, and can mitigate a range of issues resulting from faulty relays. It should be run by a trusted party, and could be replaced in the mid- to longer term with a more decentralized/trustless solution.

TBD:
* Reputation mechanics: what exactly happens on a single instance of any of the errors?
* Who should run a relay monitor, and how many instances are the sweet spot? There's an argument for having a small number, because (a) the more proposers connect to it the more it knows about relay issues, and (b) is has a lot of "power" in that it can blacklist relays.

Tl;dr: A relay monitor could observe any relay problem a validator experiences, and can tell all the other connected validators about problems with a specific relay. Thus, if a relay causes a problem with one validator, all the other connected validators would immediately know, and could avoid that relay for some time (or whatever mechanic).