Blocks V3: resolve data type - source relationship

As discussed in #377 and #386, Blocks V3 enforce BNs to produce unblinded content when execution payload is built locally, and return a blinded content only when is built remotely via builder APIs. This is only enforced via API description:
> The beacon node must return an unblinded block if it obtains the execution payload from its paired execution node. It must only return a blinded block if it obtains the execution payload header from an MEV relay.

The response header variable communicating what happened is named `execution_payload_blinded` which is not really tight to how the block has been produced, but rather the data structure sent back to VC. In theory it is possible for BN to blind locally produced blocks.

I see two possible paths here:

1. rename `execution_payload_blinded` to `execution_payload_builder` to enforce at schema level the important distinction is the block source rather than the data structure.

2. relax the assumption that blind -> builder and add a new header `execution_payload_source: enum['local', 'builder']`
there is an inconsistency in field names that is currently resolved by a spec rule saying.

I was initially strongly for `2.` but the more I think about this the more the less opinionated I become.

Review the discussion in #377 and #386 and the API description defining execution_payload_blinded. Compare the proposed header rename with adding execution_payload_source, then document or implement the selected resolution so the field names and the spec rule consistently describe the block source.

Written by the indexing model from the issue text.