Introduce changes for packages as namespaces

[b-naber]

Implements the compiler changes for RFC 3243.

After the refactorings introduced in #143734 and #149681, we can now introduce a new scope to handle namespaced crate names. Scope::NamespacedCrates has lower precedence than Scope::ModuleNonGlobs and Scope::ModuleGlobs, and is used to as a fallback whenever an Ident isn't resolvable in a Module. In cases where the root of a namespaced crate (foo in foo::bar) isn't in the extern prelude, we have to introduce a virtual module. This PR introduces a new variant VirtualMod to Res and ScopeSet::NamespacedCrates. An alternative to this approach would be to create synthetic metadata for these crates, which seemed like the less attractive option to me.

One potential downside to this approach that uses a new Scope is that in cases where a crate contains a public module whose name overlaps with the name of a namespaced crate (i.e. foo and foo::bar are dependencies and bar is a public module in foo), only the module in the base crate is used for resolution. This seems like less of a problem in practice though, as crate owners would probably only re-export the crate through that module in the first place?! Throwing an ambiguity error in this situation would be preferable, but is not possible with this implementation approach.

Namespaces are also limited to two levels, though that is by design currently, and not a limitation of the implementation approach.

r? @petrochenkov

[rustbot]

HIR ty lowering was modified

cc @fmease

[petrochenkov]

(I'll review this after another large PR, #151864.)

[petrochenkov]

@bors try @rust-timer queue

[petrochenkov]

Let's again split this into two parts to make progress.
In the first one a in --extern a::b just gets shadowed by mod a or --extern a and isn't used in case of any conflict.
In the second part we support "linking" from mod a / --extern a modules to the open namespace a that is shadowed by them.

I can see potential issues in the both parts and it would be better to deal with them separately.
I also have pretty strong personal hate towards this feature, and splitting into smaller parts will help me not abandon the reviews.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 12dbfa8 (12dbfa8f3ca3701d72022b859edf301997c37d9c, parent: 59fd4ef94daa991e6797b5aa6127e824f3067def)

[rust-timer]

Finished benchmarking commit (12dbfa8): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@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.3%	[0.2%, 0.6%]	94
Regressions ❌ (secondary)	0.5%	[0.2%, 1.4%]	47
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.2%, 0.6%]	94

Max RSS (memory usage)

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

Cycles

Results (primary -3.1%)

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)	-	-	0
Improvements ✅ (primary)	-3.1%	[-3.1%, -3.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.1%	[-3.1%, -3.1%]	1

Binary size

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

Bootstrap: 481.762s -> 483.193s (0.30%)
Artifact size: 397.93 MiB -> 398.01 MiB (0.02%)