Clarify relationship b/t builder, relay and proposer

There is an ambiguity right now with the `pubkey` contained in the `SignedBuilderBid` and the `signature` included in that message.

We want to know which builder produced a given bid/block for accountability reasons and so the signed message should include an identifier (and ideally a signature) for the builder.

Proposers also want to be able to know (and importantly, prove to others) which relays they use when obtaining blocks from the external builder network. We ideally have a separate identifier *and* signature to bind a particular relay to a bid they forward to validators.

Right now, there is only one set of (pubkey, signature) in the `SignedBuilderBid` message and it is not clear in the specs which set of actors they refer to.

To remedy, one solution is:

1) Include a builder public key and signature in the `BuilderBid` message that signs over the `header` and `value` data.
2) Include a relay public key along with an outer signature in the `SignedBuilderBid` message.

And ideally the relay validates the signature from the builder and the proposer validates the signature from the relay *and* builder. Proposers could skip builder verification if they want, or perhaps do offline in situations where it becomes relevant.

Another solution that reduces the overhead here compared to the status quo is to make the builder opaque to the proposer (so that the `SignedBuilderBid` only has pubkey and signature for the relay) with an option to also have the relay sign over the builder identity (so include a second pubkey for the builder in the `BuilderBid` message). If it is not clear from the messages exchanged in the builder APIs which builder was responsible for a block, then I think there should be a separate protocol put in place to increase accountability between builders and relays but if we go this route then this concern can be handled elsewhere.

Start by reviewing the BuilderBid and SignedBuilderBid definitions in the builder API specifications, then map which actor each public key and signature represents. Done means the specification has an agreed, unambiguous accountability and verification model for builders, relays, and proposers, including whether a separate protocol is needed.

Written by the indexing model from the issue text.