Strict fee recipient (#3363)

## Issue Addressed

Resolves #3267
Resolves #3156 

## Proposed Changes

- Move the log for fee recipient checks from proposer cache insertion into block proposal so we are directly checking what we get from the EE
- Only log when there is a discrepancy with the local EE, not when using the builder API. In the `builder-api` branch there is an `info` log when there is a discrepancy, I think it is more likely there will be a difference in fee recipient with the builder api because proposer payments might be made via a transaction in the block. Not really sure what patterns will become commong.
- Upgrade the log from a `warn` to an `error` - not actually sure which we want, but I think this is worth an error because the local EE with default transaction ordering I think should pretty much always use the provided fee recipient
- add a `strict-fee-recipient` flag to the VC so we only sign blocks with matching fee recipients. Falls back from the builder API to the local API if there is a discrepancy .




Co-authored-by: realbigsean <sean@sigmaprime.io>

validator_client/src/cli.rs

@@ -258,4 +258,17 @@ pub fn cli_app<'a, 'b>() -> App<'a, 'b> {
                     execution payload construction during proposals.")
                 .takes_value(false),
         )
+        .arg(
+            Arg::with_name("strict-fee-recipient")
+                .long("strict-fee-recipient")
+                .help("If this flag is set, Lighthouse will refuse to sign any block whose \
+                    `fee_recipient` does not match the `suggested_fee_recipient` sent by this validator. \
+                     This applies to both the normal block proposal flow, as well as block proposals \
+                     through the builder API. Proposals through the builder API are more likely to have a \
+                     discrepancy in `fee_recipient` so you should be aware of how your connected relay \
+                     sends proposer payments before using this flag. If this flag is used, a fee recipient \
+                     mismatch in the builder API flow will result in a fallback to the local execution engine \
+                     for payload construction, where a strict fee recipient check will still be applied.")
+                .takes_value(false),
+        )
 }