Track cycle function dependenciees 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	470ee4c
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/69027bd1769ffe0008a674e1

[codspeed-hq]

CodSpeed Performance Report

Merging #1018 will degrade performances by 6.52%

_{Comparing MichaReiser:cycle-fn-dependencies (470ee4c) with master (671c3dc)}

Summary

❌ 2 regressions
✅ 11 untouched

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	amortized[InternedInput]	2.1 µs	2.2 µs	-6.52%
❌	amortized[SupertypeInput]	2.8 µs	3 µs	-5.9%

[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