Clarify data column sidecar validation rules

[raulk]

Ideally this would be merged on top of #4875.

Given that columns are no longer self-sufficient for the purposes of validation and they now depend on the current block containing the bid, it's appropriate to raise this MAY to a MUST to properly deal with race conditions.

Concretely, if we receive columns before the block, clients not implementing the MAY would discard and mark them as seen, therefore preventing later copies from being reconsidered, even if the block was made available in the interim.

Note: this was probably inherited from the previous spec, which only triggered this condition if the parent of the inlined beacon block header was unknown (i.e. not in intra-slot races).

Additionally, we add the requirement to unwind and retroactively downscore forwarding peers when the column turned out to be invalid, if we had to defer its validation. Gossipsub implementations currently have no mechanism for this, but it should be farily simple to implement.

Similarly, we add the requirement that clients re-broadcast columns after passing deferred validation, thus resuming the propagation that would've taken place originally. In the current gossipsub, it's possible our peers could've sent IDONTWANTs and IHAVEs in the meantime, and implementations should already be equipped to suppress the sends in those scenarios.

[raulk]

@kasey My observation is that we're getting closer to needing the "offload then callback" mechanism for Gossipsub validation.