Right now they're `gnueabihf` and `gnueabi`, but when adding new platforms like
musl on ARM it's unfortunate to have to test for all three (`musl`, `musleabi`,
and `musleabihf`). This PR switches everything currently to `gnu`, and the new
musl targets can also use `musl` when they land.

Closes #33244

"cc" is already the default.

Android's [armeabi-v7a ABI][1] guarantees at least VFPv3-d16 hardware FPU
support, so Rust should include this in the default features for the
arm-linux-androideabi target.

[1]: https://developer.android.com/ndk/guides/abis.html

The path `/etc/rustc/` is not the default last entry in
RUST_TARGET_PATH. This was in RFC131 but was never implemented in rustc
so it was removed as part of #31117 and rust-lang/rfcs#1473.
Signed-off-by: NDoug Goldstein <cardoe@cardoe.com>

cc #32818

Automated conversion using the untry tool [1] and the following command:

```
$ find -name '*.rs' -type f | xargs untry
```

at the root of the Rust repo.

[1]: https://github.com/japaric/untry

The `data-layout` field  was made optional in 958d5638. The `os` field is always required.

Similarly to #31629 where an i586-unknown-linux-gnu target was added, there is
sometimes a desire to compile for x86 Windows as well where SSE2 is disabled.
This commit mirrors the i586-unknown-linux-gnu target and simply adds a variant
for Windows as well.

This is motivated by a recent [Gecko bug][ff] where crashes were seen on 32-bit
Windows due to users having CPUs that don't support SSE2 instructions. It was
requested that we could have non-SSE2 builds of the standard library available
so they could continue to use vanilla releases and nightlies.

[ff]: https://bugzilla.mozilla.org/show_bug.cgi?id=1253202

The initial purpose is to workaround the LLVM bug
https://llvm.org/bugs/show_bug.cgi?id=26554 for OpenBSD.

By default, the `cpu' is defined to `generic`. But with a 64bit
processor, the optimization for `generic` will use invalid asm code as
NOP (the generated code for NOP isn't a NOP).

According to #20777, "x86-64" is the right thing to do for x86_64
builds.

Closes: #31363

When building with Cargo we need to detect `feature = "jemalloc"` to enable
jemalloc, so propagate this same change to the build system to pass the right
`--cfg` argument.

It's already enabled for i686-pc-windows-gnu.

The compiler currently vendors its own version of "llvm-ar" (not literally the
binary but rather the library support) and uses it for all major targets by
default (e.g. everything defined in `src/librustc_back/target`). All custom
target specs, however, still search for an `ar` tool by default. This commit
changes this default behavior to using the internally bundled llvm-ar with the
GNU format.

Currently all targets use the GNU format except for OSX which uses the BSD
format (surely makes sense, right?), and custom targets can change the format
via the `archive-format` key in custom target specs.

I suspect that we can outright remove support for invoking an external `ar`
utility, but I figure for now there may be some crazy target relying on that so
we should leave support in for now.

Both of these targets have jemalloc disabled unconditionally right now, so using
`maybe_jemalloc` here isn't right. This fixes the case where a Linux compiler
(which is itself configured to use jemalloc) attempts to cross-compile to MinGW,
causing it to try to find an `alloc_jemalloc` crate (and failing).

This tells trans::back::write not to LLVM codegen to create .o
files but to put LLMV bitcode in .o files.

Emscripten's emcc supports .o in this format, and this is,
I think, slightly easier than making rlibs work without .o
files.

Backtraces, and the compilation of libbacktrace for asmjs, are disabled.

This port doesn't use jemalloc so, like pnacl, it disables jemalloc *for all targets*
in the configure file.

It disables stack protection.

Currently the `mipsel-unknown-linux-gnu` target doesn't actually set the
`target_arch` value to `mipsel` but it rather uses `mips`. Alternatively the
`powerpc64le` target does indeed set the `target_arch` as `powerpc64le`,
causing a bit of inconsistency between theset two.

As these are just the same instance of one instruction set, let's use
`target_endian` to switch between them and only set the `target_arch` as one
value. This should cut down on the number of `#[cfg]` annotations necessary and
all around be a little more ergonomic.

cf #31303

Currently any compilation to MIPS spits out the warning:

    'generic' is not a recognized processor for this target (ignoring processor)

Doesn't make for a great user experience! We don't encounter this in the normal
bootstrap because the cpu/feature set are set by the makefiles. Instead let's
just propagate these to the defaults for the entire target all the time (still
overridable from the command line) and prevent warnings from being emitted by
default.

This commit transitions the compiler to using the new exception handling
instructions in LLVM for implementing unwinding for MSVC. This affects both 32
and 64-bit MSVC as they're both now using SEH-based strategies. In terms of
standard library support, lots more details about how SEH unwinding is
implemented can be found in the commits.

In terms of trans, this change necessitated a few modifications:

* Branches were added to detect when the old landingpad instruction is used or
  the new cleanuppad instruction is used to `trans::cleanup`.
* The return value from `cleanuppad` is not stored in an `alloca` (because it
  cannot be).
* Each block in trans now has an `Option<LandingPad>` instead of `is_lpad: bool`
  for indicating whether it's in a landing pad or not. The new exception
  handling intrinsics require that on MSVC each `call` inside of a landing pad
  is annotated with which landing pad that it's in. This change to the basic
  block means that whenever a `call` or `invoke` instruction is generated we
  know whether to annotate it as part of a cleanuppad or not.
* Lots of modifications were made to the instruction builders to construct the
  new instructions as well as pass the tagging information for the call/invoke
  instructions.
* The translation of the `try` intrinsics for MSVC has been overhauled to use
  the new `catchpad` instruction. The filter function is now also a
  rustc-generated function instead of a purely libstd-defined function. The
  libstd definition still exists, it just has a stable ABI across architectures
  and leaves some of the really weird implementation details to the compiler
  (e.g. the `localescape` and `localrecover` intrinsics).

This target covers MIPS devices that run the trunk version of OpenWRT.

The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.

As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.