Test framework does not use realistic slot/epoch values

All tests are provided a `state` where `state.slot` is zero and `state.fork.current_version` is the fork being tested (eg `FULU_FORK_VERSION`). See the `create_genesis_state` function which does not set `slot` therefore leaving it as zero:

https://github.com/ethereum/consensus-specs/blob/365320e778965631cbef11fd93328e82a746b1f6/tests/core/pyspec/eth2spec/test/helpers/genesis.py#L142-L159

This has worked for us until very recently because the specifications were slot/epoch-agnostic; the only thing that mattered was which fork it was. I first ran into problems when adding support for the blob schedule (introduced in fulu) which defines the maximum blocks per block at a specific epoch. When adding entries to this table for deneb/electra (using their actual fork epochs) things didn't work as expected because the current slot/epoch was a much lower value (eg zero).

In `create_genesis_state`, we cannot simply set `state.slot` to `epoch_of(*_FORK_EPOCH)` because unscheduled forks (and all minimal forks) use `FAR_FUTURE_EPOCH` as a placeholder. This [has become an issue](https://github.com/ethereum/consensus-specs/pull/4484/files#r2261595169) in EIP-7782 because we cannot rely on the current epoch being greater than or equal to `EIP7782_FORK_EPOCH`. This prevents us from determining the number of slots since genesis, because we will not know when the `EIP7782` fork happened; think about when we're starting from the fork after glamsterdam. So in the testing framework, we need to figure out a different way to do this.

One idea might involve assigning temporary test-framework-only epoch values, eg 1000 epochs after the previous fork.

* `GENESIS_EPOCH: 0`
* `ALTAIR_FORK_EPOCH: 1000`
* `BELLATRIX_FORK_EPOCH: 2000`
* and so on...

But the issue with this is that clients must use the same epoch values when executing the tests.

I'm not sure how to properly fix this. It will require some brainstorming.

Sorry if these paragraphs are unclear/confusing. It's sort of a difficult issue to describe.