This PR outlines the consensus-layer changes for EIP-4844.

Changes (split across multiple docs like other hardforks, in a "feature directory" named eip4844):

• Update BeaconBlockBody to track the KZG commitments of the blobs
• Update the beacon block processing to cross validate KZG commitments and blob-transactions within the execution payload, without duplicating the transaction definition
• Introduce BlobsSidecar to sync blobs. Also note the shard field for forward compatibility - I think we can afford the mere 8 zero bytes in the blobs type to be compatible with a likely path forward with full sharding. (edit: not adding the shard field anymore)
• Introduce SignedBlobsSidecar to gossip blobs: initially the signature is available. Long-term we cannot rely on the sidecar signature being available however, blobs are synced without signture (but still verified with KZG against the beacon block). The signature functions as a spam protection in gossip.
• Introduce a temporary fork.md to define how to proceed with EIP-4844 testnet upgrade.
• Define BlobsSidecarsByRange to sync blobs: no by-root equivalent since the expectation is to sync blobs after having a reference beacon chain that misses them. Additionally the serving span is reduced to a month (data availability period caps it naturally) compared to that of 5 months of beacon blocks. And no step here, based on previous complaints dev-feedback about the beacon blocks variant.
• Define block production, including KZG commitment and versioned-hash sanity checks, and signing of the gossip object.

Possible TODO (or maybe for a later PR): the honest-validator spec covers the blob download obligation currently, but we should maybe emphasize it as a forkchoice-dependency. I am not aware of a dependency system in the existing fork-choice docs though, so it may require some refactoring (help/feedback appreciated there).

Once the EIP has gone through more testing and review, and once there is rough-consensus on inclusion in a hardfork, then we can merge the eip4844 feature-directory with other consensus features of that hardfork. The next consensus fork after the Merge, dubbed Capella currently, being the primary target.

In a follow-up PR I can work on enabling pyspec generation from this feature set, and corresponding testing. Need a stable base + format first before we refactor code-gen to support features instead of just phases.