Reduce next-solver memory usage by interning CanonicalQueryInput

[laundmo]

Goal: Reduce memory usage of next-solver especially when exceeding recursion limit

Changes:

• Added Interner::CanonicalInput associated type and surrounding interning machinery (mostly copied from ExternalConstraints)
• Changed Cx::Input to be I:CanonicalInput and adjusted other places in the code to match, including calling the interning during canonicalize_goal

Results:
According to Heaptrack (and btop) peak memory usage for compiling bevy_render (like #161748) with next-solver enabled was reduced from ~15GiB to ~4GiB since most of it was the HashMap index for NestedGoals (and search_graph::GlobalCache), which used to be 56 bytes (IIRC), but now is a single reference thanks to Interned.

Closes (maybe): #161748
Tracking issue: rust-lang/goals#113 and #160895 (comment)

r? @lcnr

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @lcnr (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions and our LLM policy for more information.

[ShoyuVanilla]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 9d1834c (9d1834c69e38df691a50a3052833ce4cb83252c2)
Base parent: 5321a4f (5321a4f40c957cf3587c055e77461febc2ebc865)

[rust-timer]

Finished benchmarking commit (9d1834c): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.2%	[0.1%, 0.2%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.4%]	3
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 1.1%, secondary 0.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.1%	[1.1%, 1.1%]	1
Regressions ❌ (secondary)	6.7%	[4.0%, 10.6%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.5%	[-2.3%, -0.7%]	7
All ❌✅ (primary)	1.1%	[1.1%, 1.1%]	1

Cycles

Results (primary -1.9%, secondary 10.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	10.0%	[10.0%, 10.0%]	1
Improvements ✅ (primary)	-1.9%	[-1.9%, -1.9%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.9%	[-1.9%, -1.9%]	1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 477.635s -> 478.315s (0.14%)
Artifact size: 402.71 MiB -> 402.95 MiB (0.06%)