Add fork transition spec tests

[ralexstokes]

Adds a test format for generating spec tests across fork boundaries.

We will immediately want to use this format to generate tests from phase 0 to altair.

Have tests to test transition with:

1. Every slot before, through, and after the slot has a block.
2. Missing the first block of the fork but otherwise all blocks.
3. Missing the last block of the fork but otherwise all blocks.
4. Missing all blocks until the first slot of the second epoch of the fork.
5. No blocks at all

Other test ideas (or chime in w/ more below!):

• Random sets of blocks across the boundary
• Alter finality across the fork boundary
• Perturb validator balances across the fork

Putting this PR up to get feedback on direction, may add further tests here or can open a dependent PR.

NOTE: this PR does not currently have the new format enabled in CI

[djrtwo]

very nice! have a handful of high level questions before we dig deeper into the meat of writing tests

[ajsutton]

Test format looks ok for Teku. Left some comments on the FlaggedContainer but it's not a big deal for us either way - happy to go with what's easiest for other clients.

[ajsutton]

Given that only the blocks are prefixed, I'd be tempted to simplify this and just record in the metadata file the number of first post-fork block. Not the slot number, but more directly recording that the first 5 blocks are pre-fork and the 6th block onwards are all post-fork. That way the test runner can decide ahead of time how to decode the file rather than having to parse the initial boolean and then switching to the appropriate block schema.

That said, in Teku we already have code to extract the slot from blocks without knowing what fork it's from so at least for us we wouldn't have any issues decoding just the raw blocks given we know the fork_epoch. We could probably work with this FlaggedContainer by just trimming the prefix it adds and then doing our usual fork-agnostic block parsing.

[ralexstokes]

yeah that is not a bad suggestion and simplifies the test format... main tension is how general we want this type of test to be -- can we think of some fork condition where a "fork index" would bind our hands? i can't think of any at the moment....

and the thing w/ taking the slot from the raw block bytes is that the position of the slot could change, e.g. in a future version of ssz. so i'd rather stay at a higher level of abstraction than needing to peer into "opaque" BeaconBlock bytes...

[ralexstokes]

note: this may need to be updated if we merge #2391

[djrtwo]

Minor comments on the tests.

Really great work on getting all the wrappers and functions to play nicely together to get a clean pattern here :)