Simplify some code for lowering THIR patterns

[Zalathar]

I've been playing around with some radically different ways of storing THIR patterns, and while those experiments haven't yet produced a clear win, I have noticed various smaller things in the existing code that can be made a bit nicer.

Some of the more significant changes:

• With a little bit of extra effort (and thoughtful use of Arc), we can completely remove an entire layer of 'pat lifetimes from the intermediate data structures used for match lowering.
• In several places, lists of THIR patterns were being double-boxed for no apparent reason.

[rustbot]

r? @Nadrieril

rustbot has assigned @Nadrieril.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in match checking

cc @Nadrieril

Some changes occurred in rustc_ty_utils::consts.rs

cc @BoxyUwU

[Zalathar]

Let's see if this has any measurable perf impact:

@bors try @rust-timer queue

[bors]

⌛ Trying commit 2f490e9 with merge efc27c7...

[Zalathar]

The double-boxing was introduced in #101139, but doesn't seem to have been mentioned at the time. I suspect it was just a consequence of doing some type-based refactoring in multiple stages, and not noticing further opportunities for simplification.

(Or perhaps there were larger obstacles at the time that have since been cleared away.)

[bors]

☀️ Try build successful - checks-actions
Build commit: efc27c7 (efc27c7f6ccf7f3fda3f29d114aca0ad24ce366d)

[rust-timer]

Finished benchmarking commit (efc27c7): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

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

Max RSS (memory usage)

Results (secondary 2.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Cycles

Results (secondary 6.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 777.275s -> 776.971s (-0.04%)
Artifact size: 328.69 MiB -> 328.70 MiB (0.00%)