Avoid multiple-blocks-same-slot in all test cases

[unnawut]

Since each block proposal is tied to a specific validator assignment, there should not be a case where there are multiple blocks or proposals for the same slot. These blocks would've been rejected before they're processed in the state transition. We're also not testing or supporting any adversarial/equivocation cases. So these tests should be restructured to have at most 1 block per slot (and by the assigned validator).

A quick claude run gave me these:

test_fork_choice_head.py

• test_head_with_two_competing_forks — slot 2 duplicated
• test_head_switches_to_heavier_fork — slot 2 duplicated
• test_head_with_deep_fork_split — slots 2, 3, 4 duplicated

test_fork_choice_reorgs.py

• test_simple_one_block_reorg — slot 2 duplicated
• test_two_block_reorg_progressive_building — slots 2, 3 duplicated
• test_three_way_fork_competition — slot 2 (three blocks), slot 3 duplicated
• test_back_and_forth_reorg_oscillation — slots 2, 3, 4 duplicated

test_lexicographic_tiebreaker.py

• test_equal_weight_forks_use_lexicographic_tiebreaker — slots 2, 3 duplicated

Be careful that it may not be as simple as bumping the slot number up as blocks need to be constructed with the right attestation weight depending on each test case's objective. Best to submit a PR for each test case change and not as a bundle.

[IlyasFardaouix]

I see the issue here is not just about bumping the slot numbers, but also making sure the blocks are constructed with the right attestation weight for each test case. I've taken a closer look at test_fork_choice_head.py and noticed that test_head_with_two_competing_forks and test_head_switches_to_heavier_fork both have duplicated slots.

To help resolve this, could you clarify how the attestation weights are currently being assigned in these tests? Are they being generated randomly or are there specific rules being applied to determine the weights?