Fix stale tracked struct values in later iterations

[MichaReiser]

This PR fixes a cycle handling-related bug where
tracked fields returned stale values from previous iterations if
they share the same hash as a tracked struct created in an earlier iteration.

The root cause of this was that TrackedStruct::update skips updating
if the tracked struct was already written in this revision (which is correct).

However, this causes issues with tracked structs with tracked fields (or hash collisions)
where the tracked struct has different values between two iterations. It's crucial
that the write happens in the later iteration.

The fix here is to not only seed the tracked struct IDs but also seed the disambiguator
map, so that the two tracked structs get different IDs. They're different tracked structs after all
(cycle handling is nothing but unrolling the query ITERATION times).

The downside of this is that using tracked structs in return positions of a cyclic query
is unlikely to ever converge because each iteration creates a new tracked struct with a separate ID.
I don't see a way around this. For those instances, use interned values which erase the identity constraint.

Extracted from #1061

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	e22c36c
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/6970d1567f7e050008ff96d3

[MichaReiser]

This always returned 1 before

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will degrade performance by 4.1%

_{Comparing MichaReiser:create-separate-tracked-structs-in-each-cycle-iteration (e22c36c) with master (2e8e6e9)}

Summary

❌ 1 (👁 1) regressed benchmark
✅ 12 untouched benchmarks

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
👁	amortized[SupertypeInput]	2.7 µs	2.8 µs	-4.1%

[ibraheemdev]

This makes sense to me, though it makes tracked structs in fixed-point a lot less useful.

Have you considered disallowing tracked structs in fixed-point entirely?

[MichaReiser]

Have you considered disallowing tracked structs in fixed-point entirely?

I haven't, but I think we also reached a state where tracked struct and specify work as expected, even if the caching across revisions might not be ideal, because we delete tracked structs too early.

That's why I'd prefer to keep support for now unless we discover new issues.