This is an alternative, and I think a more footgun-proof fix for #1014

Up to now, Salsa increments the iteration count for all cycle heads participating in a query before starting a new iteration. However, queries with cycle handling that aren't cycle heads never increment their iteration count. Instead, they always use zero (or the iteration count from the last iteration).

However, we use the iteration count in multiple places (e.g. validate_same_iteration, validate_provisional) to assert whether the most recent memo for a given key is "the same" as when a query dependent on it. For this to work, it's essential that the iteration count uniquely identify a query execution, which isn't the case now.

The way #1014 works around this is by adding an extra check to validate_same_iteration that always skips if a query has become a non-cycle head. This works, but it always requires remembering to check both the iteration count and whether the query is still in the cycle heads. In fact, we currently don't perform this check within validate_provisional because we can't; the cycle heads of a finalized memo are often empty. I'm not sure if that's the cause of the flaky test failures but it might as well be.

This PR ensures that salsa either:

• Increments the iteration count as part of the outer cycle if the query is a cycle head
• Increments the iteration count when a query with cycle handling completes (that doesn't depend on itself)

Test plan

I tested that the regression test from #1014 still passes and I ran the parallel tests with 10k iterations