Run fixpoint per strongly connected component

[MichaReiser]

Run a single fixpoint iteration for strongly connected components
to avoid exponential runtime for deeply nested cycles.

TODO:

• Documentation
• Investigate perf regressions
• Test that demonstrates the "collapsing" of nested cycles
• Review if there are any changes necessary to maybe_changed_after
• Investigate why cycle_nested_deep_conditional_changed::the_test sometimes hangs or panics

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	058fa5b
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/68e69e6062d4a300080e0186

[codspeed-hq]

CodSpeed Performance Report

Merging #999 will degrade performances by 14.34%

_{Comparing MichaReiser:fixpoint-scc-sync-table (058fa5b) with master (adf0556)}

Summary

❌ 7 regressions
✅ 5 untouched

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

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
❌	amortized[Input]	2.2 µs	2.4 µs	-10.21%
❌	amortized[InternedInput]	2.2 µs	2.3 µs	-4.29%
❌	amortized[SupertypeInput]	2.8 µs	3 µs	-6.41%
❌	new[Input]	9.8 µs	10.3 µs	-4.75%
❌	new[SupertypeInput]	15.6 µs	16.3 µs	-4.16%
❌	mutating[10]	13.7 µs	14.3 µs	-4.2%
❌	converge_diverge	126.9 µs	148.1 µs	-14.34%

[MichaReiser]

Hmm, I'm surprised that this is even slower than #995, considering that most logic now lives directly in DependencyGraph. I suppose the downside is that we incur the cost of transferring the outer head in all cases, even if the entire calculation occurs on a single thread. That might be an issue for ty, ugh.

Either way. I think there are some optimization opportunities:

1. Avoid calling unblock in more cases
2. Add a method to DependencyGraph to determine if all queries form a cycle (rather than having many wait_for calls)

[MichaReiser]

Should this be true or false???