Add register_validator endpoint

[lightclient]

This is another take on #206.

Rather than extending prepare_beacon_proposer, in this PR we create a new, separate endpoint register_validator. This addresses two pieces of feedback raised against the extension:

1. prepare_beacon_proposer performs a critical operation and probably shouldn't be encumbered by any additional responsibilities
2. register_validator will likely be executed on a different rhythm than prepare_beacon_proposer, so it feels more appropriate to separate out that logic

--

Now a short recap on why it's important this data is sent to the beacon node in the first place.

After the merge, validators will want to extract MEV from blocks. The mechanism that will facilitate this extraction a network of external builders. These builders will provide ExecutionPayloadHeaders to proposers to include in their beacon blocks with the promise that they will be paid a portion of the extracted value. From the perspective of the builder, most values in the header are deterministic depending on what the parent is. However, it is important that a few parameters remain under control of the proposer.

First is obviously the fee_recipient. Although it's not critical that the payload's actual fee_recipient be set to the proposer's preferred address (a simple transfer at the end of the block would suffice), it is crucial block builders have this information ahead of time so that they can begin constructing blocks immediately after their forkchoice moves forward.

The second parameter that is on the critical path to production is gas_limit. Strictly speaking, builders could decide whatever limit they like under the rules of consensus, however this gives a small number of builders a lot of power over this protocol parameter. Validators are more aligned with choosing a healthy gas limit, so it's best that value is left up to them.

In order to provide these two values to builders ahead of time in an form that can be authenticated, we introduce this new endpoint. By signing over these values and a timestamp, builders can determine validator's latest preferences before they are scheduled to propose.

The Builder API and spec is currently being developed in ethereum/builder-specs. A new domain type has also been proposed which will be utilized by this endpoint to avoid a conflict with consensus-level messages.

[ralexstokes]

left one comment below about defining the common types in the pyspec style somewhere and otherwise this looks great.

I strongly support this solution over #206

[djrtwo]

Looks good! minor comment on the language.
plus I prefer keeping it in the validator namespace as this is something the validator uses in it's BN communications

[lightclient]

Hi @mpetrunic, would you mind taking a look at this? Thanks!

[mpetrunic]

LGTM