In order to compare blocks coming from two sources, a validator client
must consider both consensus and execution profit - without consensus
reward information, the VC must fall back on unreliable heuristics that
can be biased towards inefficient consensus packing, specially when
execution payloads are the same which they are likely to be if the block
producer is using the same mev relay for both beacon nodes.

The consensus computation is currently not a necessary part of block
construction but given that blocks are constructed over a state, the
information necessary to compute the is already present at block
construction time.

This PR suggests a mandatory value to make validator client multiplexing
easier at the expense of beacon node complexity - if instead it is
optional, we are back to where we started where blocks cannot be
compared across implementations.

The value has to be trusted, ie the BN could be report an inaccurate
value but this is not a new risk.