refactor: Remove tracked structs from query outputs

[MichaReiser]

We currently store tracked structs twice:

• In QueryRevisions::origin (as an output): This is mainly for historic reasons because tracked structs required to be verified (mark_validated_output), but that's no longer the case since we're using generational ids.
• In QueryRevisionExtras::tracked_struct_ids: To get the tracked struct ID for a given tracked struct in a later revision (we want stable ids for better incrementality).

This PR removes tracked struct ids from origin. It requires tracking in the IdentityMap whether a tracked struct
was created in this revision (or if it's an entry from a previous revision but the tracked struct wasn't recreated)
so that we can remove now stale tracked structs in diff_outputs.

This should help reduce memory usage and potentially even improve performance because
it removes the active_query.add_output call for tracked structs and deep_verify_memo
no longer has to iterate over tracked structs.

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	6a63bff
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/689b0c1cef4f6e0008bd032b

[codspeed-hq]

CodSpeed Performance Report

Merging #969 will improve performances by ×3.4

_{Comparing MichaReiser:store-tracked-struct-ids-only-once (6a63bff) with master (a2cd1b8)}

Summary

⚡ 1 improvements
✅ 11 untouched benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	many_tracked_structs	31.8 µs	9.2 µs	×3.4

[MichaReiser]

This looks promising :)

[MichaReiser]

The results on ty's benchmarks aren't as impressive but still a solid 1-3% performance win and a reduction in memory usage.

[davidbarsky]

The memory usage, for posterity: astral-sh/ruff#19843 (comment)

[MichaReiser]

Uhhm, why?

[MichaReiser]

I don't get it. It seems that now there's a huge regression after I rebased past the persistence changes but they shouldn't matter?

[MichaReiser]

I can't reproduce this regression locally or in ty. I'm not sure what's up here with codspeed I'm sure something changed but it isn't clear what and I wonder if it's just because it now sees the LocalKey frame. I also noticed that the numbers differ by a lot if I make a change which the following commit undoes again.

[MichaReiser]

Hmm, I think this introduced a subtle regression regarding fixpoint iteration.

Before: Salsa seeded the tracked_struct_ids in every iteration with the values from the previous revision and the values from the previous iteration.

Now: Salsa seeds the tracked_struct_ids initially with the values from the previous iteration. Later iterations seed tracked_struct_ids with the values from the previous iteration but any tracked struct id that wasn't created in the first iteration isn't copied over anymore because the new QueryRevisions removes unused tracked struct ids eagerly and not only when diff_outputs is called (which we only ran between the memo from the last revision with the memo from the new revision).

Now, this is sort of a pre-existing issue for queries that aren't cycle heads because they already had the behavior that we now observe for cycle heads too.