Implement gossip validation tests from EF test vectors

[michaelsproul]

Description

There is a new test format that we can use to test our P2P verification logic:

https://github.com/ethereum/consensus-specs/blob/master/tests/formats/networking/gossip_validation.md

We should implement a handler for these tests and connect it to our various gossip verification codepaths. This will help with refactoring of those codepaths as well!

[latifkasuli]

I’d like to take this.

I did a first pass over the new networking/gossip_validation format and Lighthouse’s current EF-test/gossip validation paths. My intended approach is:

• Add a new GossipValidationHandler<E> under testing/ef_tests with runner_name = "networking" and handler_name = "gossip_validation".
• Decode meta.yaml, state.ssz_snappy, preloaded blocks, optional finalized checkpoint, optional execution payload status, and sequential message entries.
• Drive the existing Lighthouse gossip verification code paths rather than reimplementing the spec checks in the test harness.
• Compare each message result against valid | ignore | reject.
• On valid, apply the same relevant side effects needed for later messages in the vector, e.g. block import, seen attestations/aggregates, and op-pool insertion.
• Keep the first PR focused on the EF handler and minimal wiring; if the work exposes duplicated accept/ignore/reject mapping in network_beacon_processor, I can split that into a small follow-up refactor.

I noticed the current Lighthouse gossip uses SingleAttestation for subnet attestations, while the test-format table still says Attestation. I’ll handle that carefully against the fork-specific networking format rather than assuming one type for all forks.