Track cycle function dependencies as part of the cyclic query

[MichaReiser]

This fixes a bug in our fixpoint handling: the dependencies introduced by the cycle recovery function were recorded as dependencies of the outer function rather than the query with cycle handling.

This PR also requires that a cycle recovery function not introduce any new cycles, since it's unclear how to handle that.

I have the impression that we should probably to the same for cycle_initial but this is a bit trickier because we'd have to merge the input/outputs in execute_maybe_iterate. I also think it matters less because the dependencies are added to some query within the cycle and we always need to execute the cycle as a whole if any input it depends on changed. That's why I think it's probably fine if the dependencies are tracked by another cycle participant.

Test plan

I added a regression test, yay :)

Except... it revealed a bug with deep verify memo where we failed to remove the head when we early-returned. Luckily, this was easy to fix.

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	686b929
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/69055b9cc85e8400087954cc

[codspeed-hq]

CodSpeed Performance Report

Merging #1018 will not alter performance

_{Comparing MichaReiser:cycle-fn-dependencies (686b929) with master (c762869)}

Summary

✅ 13 untouched

[MichaReiser]

Before the fix, this incorrectly re-executed entry but not the cycle (which is what depends on the value).

With the fix in execute_maybe_iterate, it did re-execute the cycle, but it also re-executed entry, which is incorrect because query returns the same value (it can be backdated). Now, the behavior is what we want. entry does not get re-executed but the cycle is

[MichaReiser]

@carljm or @ibraheemdev could either of you take a look at this PR. We need this change to correctly handle diverging queries.