rustc_serialize: specialize opaque encoding and decoding of some u8 sequences

This specializes encoding and decoding of some contiguous u8 sequences to use a more efficient implementation. The default implementations process each u8 individually, but that isn't necessary for the opaque encoder and decoder. The opaque encoding for u8s is a no-op, so we can just copy entire sequences as-is, rather than process them byte by byte.

This also changes some encode and decode implementations for contiguous sequences to forward to the slice and vector implementations, so that they can take advantage of the new specialization when applicable.

Enable ASan, TSan, UBSan for aarch64-apple-darwin.

I confirmed ASan, TSan, UBSan all work for me locally with `clang` on my new Macbook Air.

~This requires https://github.com/rust-lang/llvm-project/pull/86~

Add docs note about `Any::type_id` on smart pointers

Fixes #79868.

There's an issue I've run into a couple times while using values of type `Box<dyn Any>` - essentially, calling `value.type_id()` doesn't dereference to the trait object, but uses the implementation of `Any` for `Box<dyn Any>`, giving us the `TypeId` of the container instead of the object inside it.

I couldn't find any notes about this in the documentation and - while it could be inferred from existing knowledge of Rust and the blanket implemenation of `Any` - I think it'd be nice to have a note about it in the documentation for the `any` module.

Anyways, here's a first draft of a section about it. I'm happy to revise wording :)

Remove many unnecessary manual link resolves from library

Now that #76934 has merged, we can remove a lot of these! E.g, this is
no longer necessary:

    [`Vec<T>`]: Vec

cc `@jyn514`

Give a better error for download-ci-llvm if .xz is not supported

Previously:

```
curl: (22) The requested URL returned error: 404
failed to run: curl -# -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmp6ptXJV https://ci-artifacts.rust-lang.org/rustc-builds/99ad5a1a2824fea1ecf60068fd3636beae7ea2da/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.gz
```

Now:

```
error: XZ support is required to download LLVM
help: consider disabling `download-ci-llvm` or using a different version of python
Build completed unsuccessfully in 0:00:00
```

Follow-up to https://github.com/rust-lang/rust/pull/80435.

r? `@Mark-Simulacrum`

Use Array.prototype.filter instead of open-coding

Part of #79052, originally suggested in https://github.com/rust-lang/rust/pull/79052#discussion_r523468743 by `@jyn514`

Besides making main.js smaller (always a plus), this also performs better by using the optimized filter implementation in your browser's JavaScript engine (according to `@GuillaumeGomez,` an 84% performance improvement).

Fix tests that incorrectly used `!@has` instead of `@!has`

The command is ``@!has`,` not `!`@has`.` I don't think these checks were
doing anything before! Ideally we would accept `!`@has`` as well, or at
least fail tests that use `!`@has`.` The current behavior seems to be
silently ignoring the check, which is very confusing.

r? `@GuillaumeGomez`

Previously:

```
curl: (22) The requested URL returned error: 404
failed to run: curl -# -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmp6ptXJV https://ci-artifacts.rust-lang.org/rustc-builds/99ad5a1a2824fea1ecf60068fd3636beae7ea2da/rust-dev-nightly-x86_64-unknown-linux-gnu.tar.gz
```

Now:

```
error: XZ support is required to download LLVM
help: consider disabling `download-ci-llvm` or using a different version of python
Build completed unsuccessfully in 0:00:00
```

In which we start to parse const generics defaults

As discussed in this [zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/const.20generic.20defaults), this PR extracts the parsing parts from `@JulianKnodt's` PR #75384 for a better user-experience using the newly stabilized `min_const_generics` (albeit temporary) as shown in #80507: trying to use default values on const generics currently results in parse errors, as if the user didn't use the correct syntax (which is somewhat true but also misleading).

This PR extracts (and slightly modifies in a couple places) `@JulianKnodt's` parsing code (with attribution if I've done everything correctly), AST and HIR changes, and feature gate setup.

This feature is now marked as "incomplete" and thus will also print out the expected "const generics default values are unstable" error instead of a syntax error. Note that, as I've only extracted the parsing part, the actual feature will not work at all if enabled. There will be ICEs, and inference errors on the const generics default values themselves.

Fixes #80507.

Once this merges, I'll:
- modify the const generics tracking issue to refer to the `const_generics_defaults` gate rather than the older temporary name it uses there.
- create the GH `F-const_generics_defaults` label

r? `@varkor`

Add fallible Box, Arc, and Rc allocator APIs

cc https://github.com/rust-lang/rust/issues/48043

It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs, tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary.

cc `@rust-lang/wg-allocators`

This is important to not accidentally stabilize the parsing of the syntax while it still is experimental and not formally accepted

The `const_generics_defaults` now handles them, and they correctly parse, so we can update these tests expecting a parser error .

- Adds optional default values to const generic parameters in the AST
  and HIR
- Parses these optional default values
- Adds a `const_generics_defaults` feature gate

Reduce the entry on `src/test/ui` (UI test root)

CC #73494, similar to #79776.

r? `@petrochenkov`

Add edition 2021.

🎆 Happy new ~~year~~ Rust. 🍾

This adds --edition=2021, and updates suggestions about 2018 to say "2018 *or later*".

Related Cargo PR: https://github.com/rust-lang/cargo/pull/8922

---

Edit: This adds the new edition as *unstable*. Without `-Z unstable-options`, `--edition=2021` results in:
```
$ rustc --edition=2021
error: edition 2021 is unstable and only available with -Z unstable-options.
```

Rollup of 8 pull requests

Successful merges:

 - #80323 (Update and improve `rustc_codegen_{llvm,ssa}` docs)
 - #80368 (rustdoc: Render visibilities succinctly)
 - #80514 (Fix broken ./x.py install)
 - #80519 (Take type defaults into account in suggestions to reorder generic parameters)
 - #80526 (Update LLVM)
 - #80532 (remove unnecessary trailing semicolon from bootstrap)
 - #80548 (FIx ICE on wf check for foreign fns)
 - #80551 (support pattern as const parents in type_of)

Failed merges:

 - #80547 (In which we start to parse const generics defaults)

r? `@ghost`
`@rustbot` modify labels: rollup

Part of #79052, originally suggested in https://github.com/rust-lang/rust/pull/79052#discussion_r523468743Co-authored-by: NJoshua Nelson <joshua@yottadb.com>

support pattern as const parents in type_of

nice to know that there's still stuff about rust i didn't know about 😆

fixes #80531

r? `@varkor`

FIx ICE on wf check for foreign fns

Fixes #80468

r? `@davidtwco` `@lcnr`

remove unnecessary trailing semicolon from bootstrap

Update LLVM

- [GlobalISel][IRTranslator] Fix a crash when the use of an extractvalue is a non-dominated metadata use.
- [asan] Use dynamic shadow memory position on Apple Silicon macOS

r? ``@cuviper``

Take type defaults into account in suggestions to reorder generic parameters

Fixes #80512

Fix broken ./x.py install

During my tarball refactorings in https://github.com/rust-lang/rust/pull/79788 I changed the directory layout used by the tarball generation code, and that broke the other parts of rustbuild which hardcoded the paths of those directories. Namely, `./x.py install` relied on the uncompressed copy of the tarball left behind by `fabricate`/`rust-installer`, causing https://github.com/rust-lang/rust/issues/80494.

While the easy fix for https://github.com/rust-lang/rust/issues/80494 would've been to just update the hardcoded paths to match the new structure, that fix would leave us in the same situation if we were to change the directory layout again in the future. Instead I refactored the code to return a `GeneratedTarball` struct as the output of all the dist steps, and I put all the paths the rest of rustbuild needs to care about in its fields. That way, future changes to `src/bootstrap/tarball.rs` will not break other stuff.

This PR is best reviewed commit-by-commit.
r? `@Mark-Simulacrum`
`@rustbot` modify labels: beta-nominated beta-accepted T-release

rustdoc: Render visibilities succinctly

Fixes #79139.

r? `@jyn514`

Update and improve `rustc_codegen_{llvm,ssa}` docs

Fixes #75342.

These docs were very out of date and misleading. They even said that
they codegen'd the *AST*!

For some reason, the `rustc_codegen_ssa::base` docs were exactly
identical to the `rustc_codegen_llvm::base` docs. They didn't really
make sense, because they had LLVM-specific information even though
`rustc_codegen_ssa` is supposed to be somewhat generic. So I removed
them as they were misleading.

r? ``@pnkfelix`` maybe?

The command is `@!has`, not `!@has`. I don't think these checks were
doing anything before! Ideally we would accept `!@has` as well, or at
least fail tests that use `!@has`. The current behavior seems to be
silently ignoring the check, which is very confusing.