Make p2p interface specifications executable/testable

[jtraglia]

For each fork's version of the p2p-interface specifications, we should make the verification checks executable functions. Eg:

consensus-specs/specs/phase0/p2p-interface.md

Lines 437 to 464 in 9c68080

	- _[IGNORE]_ The block is not from a future slot (with a
	`MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance) -- i.e. validate that
	`signed_beacon_block.message.slot <= current_slot` (a client MAY queue future
	blocks for processing at the appropriate slot).
	- _[IGNORE]_ The block is from a slot greater than the latest finalized slot --
	i.e. validate that
	`signed_beacon_block.message.slot > compute_start_slot_at_epoch(store.finalized_checkpoint.epoch)`
	(a client MAY choose to validate and store such blocks for additional purposes
	-- e.g. slashing detection, archive nodes, etc).
	- _[IGNORE]_ The block is the first block with valid signature received for the
	proposer for the slot, `signed_beacon_block.message.slot`.
	- _[REJECT]_ The proposer signature, `signed_beacon_block.signature`, is valid
	with respect to the `proposer_index` pubkey.
	- _[IGNORE]_ The block's parent (defined by `block.parent_root`) has been seen
	(via gossip or non-gossip sources) (a client MAY queue blocks for processing
	once the parent block is retrieved).
	- _[REJECT]_ The block's parent (defined by `block.parent_root`) passes
	validation.
	- _[REJECT]_ The block is from a higher slot than its parent.
	- _[REJECT]_ The current `finalized_checkpoint` is an ancestor of `block` --
	i.e.
	`get_checkpoint_block(store, block.parent_root, store.finalized_checkpoint.epoch) == store.finalized_checkpoint.root`
	- _[REJECT]_ The block is proposed by the expected `proposer_index` for the
	block's slot in the context of the current shuffling (defined by
	`parent_root`/`slot`). If the `proposer_index` cannot immediately be verified
	against the expected shuffling, the block MAY be queued for later processing
	while proposers for the block's branch are calculated -- in such a case _do
	not_ `REJECT`, instead `IGNORE` this message.

Then, we can create new test formats & reference tests for clients.

This is not an urgent feature, but it would be very nice to have. I would like to do this myself after the Fulu upgrade.