[ty] Reduce memory usage of TupleSpec and TupleType

[AlexWaygood]

Summary

Fixes astral-sh/ty#956. Use boxed slices rather than Vecs where possible for types interned in the salsa database, to save on memory.

Test Plan

Existing tests

[github-actions]

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

Memory usage changes were detected when running on open source projects

sphinx (https://github.com/sphinx-doc/sphinx)
-     struct fields = ~17MB
+     struct fields = ~16MB

[AlexWaygood]

Not sure if this is worth it — CI reports no significant memory-usage reductions in the memory.txt projects, and codspeed reports 1% regressions on several benchmarks.

Tomorrow I'll try getting some memory-usage reports for projects that we know have some complicated tuple types in them, such as colour-science and static-frame. Opening up for review now anyway, to see what folks think of the approach!

[MichaReiser]

You probably want to wait for #19790 (or rebase on top) to get a full picture. The memory report today only accounts for queries (heap and stack size) and the stack size of tracked struct, but it doesn't account for the heap size of tracked structs. That means, the only memory reduction you'd see is from reducing the stack memory from 48 + stack_size::<T> to 32 + stack_size::<T>. That on its own might still be significant but only if we create a large number of tuple specs (and intern them)

[MichaReiser]

This is the full memory report comparison from running on a large project. You can see how the tuple type's stack size has become much smaller. It's just not significant in overall terms because there aren't many enough (or put differently, some other queries use up so much space that the tuple type improvement is negligible). I suggest re-running the analysis with #19790

https://www.diffchecker.com/ZkHpFHCN/

Edit: The reason why we have different counts for some ingredients is because ty still panics when analysing some files and that leads to non-deterministic results.

[MichaReiser]

I just ran main with the salsa struct memory usage information and the total memory usage for tuples is only:

`TupleType`                                        metadata=6.65MB   fields=13.88MB  count=118827

So i don't think this will lead to a very significant improvement

[AlexWaygood]

I tried running memory reports on colour-science and static-frame, which were codebases I thought might be interesting because we know operations on tuple types are quite hot when typechecking those codebases. The top-level memory usage for both those codebases is the same on main and with this PR. The memory taken up by TupleType does go down, but it's a small fraction of the overall memory usage

Project	TupleType memory usage (main)	TupleType memory usage (this PR)	Total memory usage (main and this PR)
static-frame	metadata: 0.98MB fields: 1.91MB	metadata: 0.98MB fields: 1.58MB	348MB
colour	metadata: 0.12MB fields: 0.44MB	metadata: 0.12MB fields: 0.39MB	298MB

(All measurements done by executing TY_MEMORY_REPORT=full cargo run --release --manifest-path ../ruff/Cargo.toml -p ty check --quiet)

That does seem like a pretty decent reduction in memory usage on tuples in static-frame, even if it's a small slice of the overall pie. Using boxed slices is also consistent with what we do elsewhere for our Salsa-interned structs, and is more expressive of the fact that types are immutable once they're stored in the Salsa cache. I think the main question is whether this is worth the increase in code complexity -- I could go either way on that.

Performance is in the noise -- some benchmarks are showing tiny speedups, other ones tiny slowdowns.

[MichaReiser]

I think the immutability of TupleSpec is a nice side effect that I value more than the tiny memory improvement :)

[MichaReiser]

Eh, sphinx has a memory reduction 😆