Fix attestation step order in FCR test vectors

[eserilev]

The FCR test vectors list each slot's attestation steps before the tick that moves the test to the next slot. The test generator applies them after that tick. When lighthouse replays the steps as written, we reject the attestation as a future-slot attestation.

• FCRTest.attest records the attestation step when it creates the attestation
• FCRTest.next_slot ticks first then applies the attestation

This PR fixes this issue by recording the attestation step in apply_attestations, right after on_attestation runs (instead of when its created). This allows for the attestation step to land after the tick. Also had to tweak some things to make sure duplicate attestation steps werent created.

AI disclosure: Fable helped me debug, find the issue and write a fix. I've done a self review and understand the issue.

[syjn99]

LGTM from Prysm side: we're using a hacky way to accommodate this issue:

https://github.com/OffchainLabs/prysm/blob/e195fafbc3a333ae647c86b36ec5e6b608cb9f5e/testing/spectest/shared/common/forkchoice/builder.go#L203-L208

[mkalinin]

Don't LH and Prysm test runners cache attestations to apply them after the tick like it would happen in a real network?

[eserilev]

Yeah but we disable queueing future attestations when running fork choice compliance and FCR tests