rustdoc: Avoid re-HIR-ty-lowering tys & const args where possible

[fmease]

_{(No LLM was or will be used by me during the entire creation process of this PR)}

[fmease]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: bcb47ea (bcb47ead48b72b7a7467bb2a80cc83101b1aa48d)
Base parent: 9a9d194 (9a9d1946d1e119676b7a6a8a26a264061e61027d)

[rust-timer]

Finished benchmarking commit (bcb47ea): comparison URL.

Overall result: ✅ improvements - no action needed

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.

@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
Improvements ✅ (primary)	-1.9%	[-3.8%, -0.2%]	6
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.9%	[-3.8%, -0.2%]	6

Max RSS (memory usage)

Results (primary -2.4%, 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)	0.9%	[0.9%, 0.9%]	1
Improvements ✅ (primary)	-4.1%	[-4.9%, -3.3%]	2
Improvements ✅ (secondary)	-2.7%	[-2.7%, -2.7%]	1
All ❌✅ (primary)	-2.4%	[-4.9%, 1.1%]	3

Cycles

Results (primary -3.1%, secondary -7.6%)

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)	3.0%	[2.6%, 3.6%]	3
Improvements ✅ (primary)	-3.1%	[-4.5%, -1.7%]	2
Improvements ✅ (secondary)	-13.9%	[-25.6%, -4.6%]	5
All ❌✅ (primary)	-3.1%	[-4.5%, -1.7%]	2

Binary size

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

Bootstrap: 489.957s -> 487.674s (-0.47%)
Artifact size: 407.04 MiB -> 406.34 MiB (-0.17%)

[fmease]

The main improvement most likely comes from the change described in #162916 (comment) in PR #162916. Since that PR also makes that change (it forcibly falls out of major refactorings), I'll wait it to get merged & then re-perf this PR.