Auto merge of #23011 - nagisa:the-war-of-symbol-and-symbol, r=pnkfelix

We provide tools to tell what exact symbols to emit for any fn or static, but
don’t quite check if that won’t cause any issues later on. Some of the issues
include LLVM mangling our names again and our names pointing to wrong locations,
us generating dumb foreign call wrappers, linker errors, extern functions
resolving to different symbols altogether (`extern {fn fail();} fail();` in some
cases calling `fail1()`), etc.

Before the commit we had a function called `note_unique_llvm_symbol`, so it is
clear somebody was aware of the issue at some point, but the function was barely
used, mostly in irrelevant locations.

Along with working on it I took liberty to start refactoring trans/base into
a few smaller modules. The refactoring is incomplete and I hope I will find some
motivation to carry on with it.

This is possibly a [breaking-change] because it makes dumbly written code
properly invalid.

This fixes all those issues about incorrect use of #[no_mangle] being not reported/misreported/ICEd by the compiler.

NB. This PR does not attempt to tackle the parallel codegen issue that was mentioned in https://github.com/rust-lang/rust/pull/22811, but I believe it should be very straightforward in a follow up PR by modifying `trans::declare::get_defined_value` to look at all the contexts.

cc @alexcrichton @huonw @nrc because you commented on the original RFC issue.

EDIT: wow, this became much bigger than I initially intended.

diff --cc src/librustc_trans/trans/common.rs
Simple merge

diff --cc src/librustc_trans/trans/controlflow.rs
Simple merge

diff --cc src/librustc_trans/trans/debuginfo.rs
Simple merge

diff --cc src/libsyntax/attr.rs
Simple merge