Lint against named asm labels

This adds a deny-by-default lint to prevent the use of named labels in inline `asm!`.  Without a solution to #81088 about whether the compiler should rewrite named labels or a special syntax for labels, a lint against them should prevent users from writing assembly that could break for internal compiler reasons, such as inlining or anything else that could change the number of actual inline assembly blocks emitted.

This does **not** resolve the issue with rewriting labels, that still needs a decision if the compiler should do any more work to try to make them work.

Specialize `Vec::clone_from` for `Copy` types

This should improve performance and reduce code size.

This also improves `clone_from` for `String`, `OsString` and `PathBuf`.

Try filtering out non-const impls when we expect const impls

**TL;DR**: Associated types on const impls are now bounded; we now disallow calling a const function with bounds when the specified type param only has a non-const impl.

r? `@oli-obk`

Move some UI tests to more suitable subdirs

The classifui result: https://gist.github.com/JohnTitor/c9e00840990b5e4a8fc562ec3571e427/e06c42226c6038da91e403c33b9947843420cf44

Some notes:
- backtrace-debuginfo.rs: previously I skipped this, I'm still not sure what the best dir is. Any ideas?
- estr-subtyping.rs: Seems a quite old test so removed, shouldn't?
- deref-suggestion.rs: moved to inference as `suggestions` is not an ideal dir.
- issue-43023.rs: a bit misclassified, moved to `derives`

cc #73494
r? `@petrochenkov`

Name the captured upvars for closures/generators in debuginfo

Previously, debuggers print closures as something like
```
y::main::closure-0 (0x7fffffffdd34)
```
The pointer actually references to an upvar. It is not very obvious, especially for beginners.

It's because upvars don't have names before, as they are packed into a tuple. This PR names the upvars, so we can expect to see something like
```
y::main::closure-0 {_captured_ref__b: 0x[...]}
```

r? `@tmandry`
Discussed at https://github.com/rust-lang/rust/pull/84752#issuecomment-831639489 .

Update browser-ui-test package version

r? `@notriddle`

Updates favicon order of precedence as it matters to Chrome

Hi, this updates #75438 to fix an order of precedence issue for Chrome. Unfortunately, the last favicon defined wins when it comes to Chrome, hence the primary icon being placed last. I [brought it up](https://bugs.chromium.org/p/chromium/issues/detail?id=1104663) with the Chromium team last year, but so far it's a non-issue.

I've created an example website that mimics the behaviour in Chrome. https://sl4m.github.io/chrome-favicon/

This is what I'm seeing at the moment when viewing https://doc.rust-lang.org/core/index.html in Chrome. It's falling back to the PNG.

<img width="80" alt="Screenshot 2021-08-12 at 21 11 58" src="https://user-images.githubusercontent.com/47347/129304041-b598213e-fcd3-4df1-addb-e6feac6c35b1.png">

Point to where clause for GATs to add bound

Fixes #84931

r? `@estebank`

Associated functions that contain extern indicator or have `#[rustc_std_internal_symbol]` are reachable

Previously these fails to link with ``undefined reference to `foo'``:

<details>
<summary>Example 1</summary>

```rs
struct AssocFn;

impl AssocFn {
    #[no_mangle]
    fn foo() {}
}

fn main() {
    extern "Rust" {
        fn foo();
    }
    unsafe { foo() }
}
```
([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=f1244afcdd26e2a28445f6e82ca46b50))
</details>

<details>
<summary>Example 2</summary>

```rs
#![crate_name = "lib"]
#![crate_type = "lib"]

struct AssocFn;

impl AssocFn {
    #[no_mangle]
    fn foo() {}
}
```
```rs
extern crate lib;

fn main() {
    extern "Rust" {
        fn foo();
    }
    unsafe { foo() }
}
```
</details>

But I believe they should link successfully, because this works:
<details>

```rs
#[no_mangle]
fn foo() {}

fn main() {
    extern "Rust" {
        fn foo();
    }
    unsafe { foo() }
}
```
([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=789b3f283ee6126f53939429103ed98d))
</details>

This PR fixes the problem, by adding associated functions that have "custom linkage" to `reachable_set`, just like normal functions.

I haven't tested whether #76211 and [Miri](https://github.com/rust-lang/miri/issues/1837) are fixed by this PR yet, but I'm submitting this anyway since this fixes the examples above.

I added a `run-pass` test that combines my two examples above, but I'm not sure if that's the right way to test this. Maybe I should add / modify an existing codegen test (`src/test/codegen/export-no-mangle.rs`?) instead?

Closure lint wording

Some small changes to the wording of the closure migration lint.

r? `@Aaron1011`

Rollup of 4 pull requests

Successful merges:

 - #87795 (Avoid ICE caused by suggestion)
 - #87966 (Fix `command-create-pidfd` test inside unprivileged Docker containers)
 - #87969 (Revert "Rollup merge of #87779 - Aaron1011:stmt-ast-id, r=petrochenkov")
 - #88005 (Add rustdoc GUI test for headers)

Failed merges:

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

Add rustdoc GUI test for headers

Add test for #87861.

r? ``@notriddle``

Revert "Rollup merge of #87779 - Aaron1011:stmt-ast-id, r=petrochenkov"

Fixes #87877

This change interacts badly with `noop_flat_map_stmt`,
which synthesizes multiple statements with the same `NodeId`.

I'm working on a better fix that will still allow us to
remove this special case. For now, let's revert the change
to fix the ICE.

This reverts commit a4262cc9, reversing
changes made to 8ee962f8.

Fix `command-create-pidfd` test inside unprivileged Docker containers

In `src/test/ui/command/command-create-pidfd.rs` (added #81825), the detection code to skip the test on unsupported platforms doesn't account for unprivileged Docker containers (CI uses privileged containers), which leads to a test failure as you can't call the `clone3` syscall in that environment. This PR enhances the detection code to also consider unprivileged containers.

Avoid ICE caused by suggestion

When suggesting dereferencing something that can be iterable in a `for`
loop, erase lifetimes and use a fresh `ty::ParamEnv` to avoid 'region
constraints already solved' panic.

Fix #87657, fix #87709, fix #87651.