I wanted to update mdbook's version. This ended up updating a bunch of other stuff too.

This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.

[RFC 1974]: https://github.com/rust-lang/rfcs/pull/197

The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.

cc #27389

This commit migrates the in-tree `libcompiler_builtins` to the upstream version
at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version
has a number of intrinsics written in Rust and serves as an in-progress rewrite
of compiler-rt into Rust. Additionally it also contains all the existing
intrinsics defined in `libcompiler_builtins` for 128-bit integers.

It's been the intention since the beginning to make this transition but
previously it just lacked the manpower to get done. As this PR likely shows it
wasn't a trivial integration! Some highlight changes are:

* The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes
  across platforms and also some refactorings to make the intrinsics easier to
  read. The additional testing added there also fixed a number of integration
  issues when pulling the repository into this tree.

* LTO with the compiler-builtins crate was fixed to link in the entire crate
  after the LTO process as these intrinsics are excluded from LTO.

* Treatment of hidden symbols was updated as previously the
  `#![compiler_builtins]` crate would mark all symbol *imports* as hidden
  whereas it was only intended to mark *exports* as hidden.

... to get https://github.com/rust-lang/cargo/pull/4244 and
https://github.com/rust-lang/cargo/pull/4246

`--emit=llvm-ir` looks like this now:

```
; <alloc::vec::Vec<T> as core::ops::index::IndexMut<core::ops::range::RangeFull>>::index_mut
; Function Attrs: inlinehint uwtable
define internal { i8*, i64 } @"_ZN106_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..index..IndexMut$LT$core..ops..range..RangeFull$GT$$GT$9index_mut17h7f7b576609f30262E"(%"alloc::vec::Vec<u8>"* dereferenceable(24)) unnamed_addr #0 {
start:
  ...
```

cc https://github.com/integer32llc/rust-playground/issues/15

This commit integrates the `jobserver` crate into the compiler. The crate was
previously integrated in to Cargo as part of rust-lang/cargo#4110. The purpose
here is to two-fold:

* Primarily the compiler can cooperate with Cargo on parallelism. When you run
  `cargo build -j4` then this'll make sure that the entire build process between
  Cargo/rustc won't use more than 4 cores, whereas today you'd get 4 rustc
  instances which may all try to spawn lots of threads.

* Secondarily rustc/Cargo can now integrate with a foreign GNU `make` jobserver.
  This means that if you call cargo/rustc from `make` or another
  jobserver-compatible implementation it'll use foreign parallelism settings
  instead of creating new ones locally.

As the number of parallel codegen instances in the compiler continues to grow
over time with the advent of incremental compilation it's expected that this'll
become more of a problem, so this is intended to nip concurrent concerns in the
bud by having all the tools to cooperate!

Note that while rustc has support for itself creating a jobserver it's far more
likely that rustc will always use the jobserver configured by Cargo. Cargo today
will now set a jobserver unconditionally for rustc to use.

This commit deletes the in-tree `getopts` crate in favor of the crates.io-based
`getopts` crate. The main difference here is with a new builder-style API, but
otherwise everything else remains relatively standard.

Closes rust-lang/cargo#4189

Brings in a few regression fixes on the Cargo side, updates the rls to work
with the newer Cargo, and also updates other crates.io dependencies to pull in
various bug fixes and such.

The rationale is that BOM stripping is needed for lazy source loading
for external crates, and duplication can be avoided by moving the
corresponding functionality to libsyntax_pos.

Fixes build with libressl
Signed-off-by: NMarc-Antoine Perennou <Marc-Antoine@Perennou.com>

Brings in some perf improvements!

Fixes #38584

It now marks a few whitelisted extensions as executable in the tarball,
so Windows packages can be extracted on other platforms and directly
execute install.sh.

It also includes a fix for the chmod on bulk dirs, so now the html docs
won't be marked executable en masse.

Fixes #42121
r? @alexcrichton

This should include a fix for rust-lang/cargo#4091 with an updated version of
libgit2.

Closes rust-lang/cargo#4091

Contains a fix for rust-lang/cargo#4081

This avoids double compiled Cargo. Hopefully this would speed up (extended) compilation for ~10m.

Notes: when updating Cargo submodule, the replacement version may also need to be updated.

fixes build when DESTDIR is set
Signed-off-by: NMarc-Antoine Perennou <Marc-Antoine@Perennou.com>

This does not actually improve build times, since it still depends
on rustc_trans, but is better layering and fits the multi-backend
future slightly better.

Consequently, session creation can no longer initialize LLVM.
The few places that use the compiler without going through
rustc_driver/CompilerCalls thus need to be careful to manually
initialize LLVM (via rustc_trans!) immediately after session
creation.

This means librustc is not rebuilt when LLVM changes.

Move the code for loading metadata from rlibs and dylibs from
rustc_metadata into rustc_trans, and introduce a trait to avoid
introducing a direct dependency on rustc_trans.

This means rustc_metadata is no longer rebuilt when LLVM changes.