If the Rust LLVM fork is used, enable the -mergefunc-use-aliases
flag, which will create aliases for merged functions, rather than
inserting a call from one to the other.

A number of codegen tests needed to be adjusted, because functions
that previously fell below the thunk limit are now being merged.
Merging is prevented either using -C no-prepopulate-passes, or by
making the functions non-identical.

I expect that this is going to break something, somewhere, because
it isn't able to deal with aliases properly, but we won't find out
until we try :)

This fixes #52651.

This commit updates the compiler to allow the `#[no_mangle]` (and
`#[export_name]` attributes) to be located anywhere within a crate.
These attributes are unconditionally processed, causing the compiler to
always generate an exported symbol with the appropriate name.

After some discussion on #54135 it was found that not a great reason
this hasn't been allowed already, and it seems to match the behavior
that many expect! Previously the compiler would only export a
`#[no_mangle]` symbol if it were *publicly reachable*, meaning that it
itself is `pub` and it's otherwise publicly reachable from the root of
the crate. This new definition is that `#[no_mangle]` *is always
reachable*, no matter where it is in a crate or whether it has `pub` or
not.

This should make it much easier to declare an exported symbol with a
known and unique name, even when it's an internal implementation detail
of the crate itself. Note that these symbols will persist beyond LTO as
well, always making their way to the linker.

Along the way this commit removes the `private_no_mangle_functions` lint
(also for statics) as there's no longer any need to lint these
situations. Furthermore a good number of tests were updated now that
symbol visibility has been changed.

Closes #54135

Smaller platforms don't merge the loads the same way.

LLVM isn't able to remove the alloca for the unaligned block in the SIMD tail in some cases, so doing this helps SRoA work in cases where it currently doesn't.  Found in the `replace_with` RFC discussion.

If an error message is emitted that spans several files, only the
primary file currently has line and column data attached. This is
useful information, even in files other than the one in which the error
occurs. We can often work out which line and column the error
corresponds to in other files — in this case it is helpful to add them
(in the case of ambiguity, the first relevant line/column is picked,
which is still helpful than none).

Closes #36792. Closes #38091. Closes #39687. Closes #42148. Closes #42956.

Closes #2569

This was previously implemented, and it just needed a snapshot to go through

A few features are now hidden behind various #[feature(...)] directives. These
include struct-like enum variants, glob imports, and macro_rules! invocations.

Closes #9304
Closes #9305
Closes #9306
Closes #9331

Also add a test to help prevent this from getting out of sync again.

Some are xfailed, some not, some existing ones get un-xfailed.

The tests have consts defined both before and after their uses in order
to prevent bugs that depend on the order in which they are translated.