This is a follow-up to #70123, which added `llvm-config --libdir` to the
`LIBRARY_PATH` for rustc tools. We need the same for "run-make-fulldeps"
and "ui-fulldeps" tests which depend on compiler libraries, implicitly
needing to link to `-lLLVM` as well.

Without `Compiletest.path` set running `x.py test src/test/rustdoc-js` would run the `rustdoc-js` test suite with everything filtered out.

As this was the only place setting `Compiletest.path` to `None` this removes the `Option` wrapper as well.

Previous implementation used a single mode type to store various pieces
of otherwise loosely related information:

* Whether debuginfo mode is in use or not.
* Which debuggers should run in general.
* Which debuggers are enabled for particular test case.

The new implementation introduces a separation between those aspects.
There is a single debuginfo mode parametrized by a debugger type.
The debugger detection is performed first and a separate configuration
is created for each detected debugger. The test cases are gathered
independently for each debugger which makes it trivial to implement
support for `ignore` / `only` conditions.

Functional changes:

* A single `debuginfo` entry point (rather than `debuginfo-cdb`, `debuginfo-gdb+lldb`, etc.).
* Debugger name is included in the test name.
* Test outputs are placed in per-debugger directory.
* Fixed spurious hash mismatch. Previously, the config mode would change
  from `DebugInfoGdbLldb` (when collecting tests) to `DebugInfoGdb` or
  `DebugInfoLldb` (when running them) which would affect hash computation.
* PYTHONPATH is additionally included in gdb hash.
* lldb-python and lldb-python-dir are additionally included in lldb hash.

This reverts commit 3ed3b8bb, reversing
changes made to 99b89533.

We will reland a similar patch at a future date but for now we should get a nightly
released in a few hours with the parallel patch, so this should be
reverted to make sure that the next nightly is not parallel-enabled.

These depend on rustc being bug-free and it looks like that's not
currently entirely the case (e.g., we know of at least one bug that
introduces nondeterminism).

This commit builds on #65501 continue to simplify the build system and
compiler now that we no longer have multiple LLVM backends to ship by
default. Here this switches the compiler back to what it once was long
long ago, which is linking LLVM directly to the compiler rather than
dynamically loading it at runtime. The `codegen-backends` directory of
the sysroot no longer exists and all relevant support in the build
system is removed. Note that `rustc` still supports a dynamically loaded
codegen backend as it did previously, it just no longer supports
dynamically loaded codegen backends in its own sysroot.

Additionally as part of this the `librustc_codegen_llvm` crate now once
again explicitly depends on all of its crates instead of implicitly
loading them through the sysroot. This involved filling out its
`Cargo.toml` and deleting all the now-unnecessary `extern crate`
annotations in the header of the crate. (this in turn required adding a
number of imports for names of macros too).

The end results of this change are:

* Rustbuild's build process for the compiler as all the "oh don't forget
  the codegen backend" checks can be easily removed.
* Building `rustc_codegen_llvm` is much simpler since it's simply
  another compiler crate.
* Managing the dependencies of `rustc_codegen_llvm` is much simpler since
  it's "just another `Cargo.toml` to edit"
* The build process should be a smidge faster because there's more
  parallelism in the main rustc build step rather than splitting
  `librustc_codegen_llvm` out to its own step.
* The compiler is expected to be slightly faster by default because the
  codegen backend does not need to be dynamically loaded.
* Disabling LLVM as part of rustbuild is still supported, supporting
  multiple codegen backends is still supported, and dynamic loading of a
  codegen backend is still supported.

With #65251 landed there's no need to build two LLVM backends and ship
them with rustc, every target we have now uses the same LLVM backend!

This removes the `src/llvm-emscripten` submodule and additionally
removes all support from rustbuild for building the emscripten LLVM
backend. Multiple codegen backend support is left in place for now, and
this is intended to be an easy 10-15 minute win on CI times by avoiding
having to build LLVM twice.

 - Compatible with Emscripten 1.38.46-upstream or later upstream.
 - Refactors the Emscripten target spec to share code with other wasm
   targets.
 - Replaces the old incorrect wasm32 C call ABI with the correct one,
   preserving the old one as wasm32_bindgen_compat for wasm-bindgen
   compatibility.
 - Updates the varargs ABI used by Emscripten and deletes the old one.
 - Removes the obsolete wasm32-experimental-emscripten target.
 - Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.

This reverts commit 78700507, reversing
changes made to 2e724480.

 - Refactors the Emscripten target spec to share code with other wasm
   targets.
 - Replaces the incorrect wasm32 C call ABI with the old asmjs
   version, which is correct for both wasm32 and JS.
 - Updates the varargs ABI used by Emscripten and deletes the old one.
 - Removes the obsolete wasm32-experimental-emscripten target.
 - Temporarily makes Emscripten targets use panic=abort by default
   because supporting unwinding will require an LLVM patch.

This logic is *super* old and can be tweaked and moved into `builder.rs`

This commit changes the return type of `Builder::cargo` to return a
builder that allows dynamically adding more `RUSTFLAGS` values
after-the-fact. While not used yet, this will later be used to delete
more of `rustc.rs`

Cargo has a native enviroment variable for this.

This commit removes the `wasm_syscall` feature from the
wasm32-unknown-unknown build of the standard library. This feature was
originally intended to allow an opt-in way to interact with the
operating system in a posix-like way but it was never stabilized.
Nowadays with the advent of the `wasm32-wasi` target that should
entirely replace the intentions of the `wasm_syscall` feature.

Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.

Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.

After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.

This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.