Don't omit comma when suggesting wildcard arm after macro expr

* Also adds `Span::eq_ctxt` to consolidate the various usages of `span.ctxt() == other.ctxt()`
* Also fixes an unhygenic usage of spans which caused the suggestion to render weirdly when we had one arm match in a macro
* Also always suggests a comma (i.e. even after a block) if we're rendering a wildcard arm in a single-line match (looks prettier 🌹)

Fixes #94866

Drop magic value 3 from code

Magic value 3 is used to create state for a yield point. It is in fact
the number of reserved variants.

Lift RESERVED_VARIANTS out to module scope and use it instead.

Rollup of 8 pull requests

Successful merges:

 - #93080 (Implement `core::slice::IterMut::as_mut_slice` and `impl<T> AsMut<[T]> for IterMut<'_, T>`)
 - #94855 (Panic when advance_slices()'ing too far and update docs.)
 - #96609 (Add `{Arc, Rc}::downcast_unchecked`)
 - #96719 (Fix the generator example for `pin!()`)
 - #97149 (Windows: `CommandExt::async_pipes`)
 - #97150 (`Stdio::makes_pipe`)
 - #97837 (Document Rust's stance on `/proc/self/mem`)
 - #98159 (Include ForeignItem when visiting types for WF check)

Failed merges:

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

Include ForeignItem when visiting types for WF check

Addresses Issue 95665 by including `hir::Node::ForeignItem` as a valid
type to visit in `diagnostic_hir_wf_check`.

Fixes #95665

Document Rust's stance on `/proc/self/mem`

Add documentation to `std::os::unix::io` describing Rust's stance on
`/proc/self/mem`, treating it as an external entity which is outside
the scope of Rust's safety guarantees.

`Stdio::makes_pipe`

Wrappers around `std::process::Command` may want to be able to override pipe creation. However, [`std::process::Stdio`](https://doc.rust-lang.org/std/process/struct.Stdio.html) is opaque so there's no way to tell if `Command` was told to create new pipes or not.

This is in some ways a more generic (and cross-platform) alternative to #97149. However, unlike that feature, this comes with the price of the user needing to actually create their own pipes rather than reusing the std one. So I think it stands (or not) on its own.

# Example

```rust
#![feature(stdio_makes_pipe)]
use std::process::Stdio;

let io = Stdio::piped();
assert_eq!(io.makes_pipe(), true);
```

Windows: `CommandExt::async_pipes`

Discussed in https://github.com/tokio-rs/tokio/issues/4670 was the need for third party crates to be able to force `process::Command::spawn` to create pipes as async.

This implements the suggestion for a `async_pipes` method that gives third party crates that option.

# Example:

```rust
use std::process::{Command, Stdio};

Command::new("cmd")
    .async_pipes(true)
    .stdin(Stdio::piped())
    .stdout(Stdio::piped())
    .stderr(Stdio::piped())
    .spawn()
    .unwrap();
```

Fix the generator example for `pin!()`

The previous generator example is not actually self-referential, since the reference is created after the yield.

CC #93178 (tracking issue)

Add `{Arc, Rc}::downcast_unchecked`

Part of #90850.

Panic when advance_slices()'ing too far and update docs.

This updates advance_slices() to panic when advancing too far, like advance() already does. And updates the docs to say so.

See https://github.com/rust-lang/rust/issues/62726#issuecomment-1065253213

Implement `core::slice::IterMut::as_mut_slice` and `impl<T> AsMut<[T]> for IterMut<'_, T>`

As per [the zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.60std.3A.3Aslice.3A.3AIterMut.3A.3Aas_mut_slice.60), the `AsMut` impl has been commented out, with a comment near the `#[unstable(...)]` to uncomment it when `as_mut_slice` gets stabilized.

Obligation forest tweaks

A few minor improvements to the code.

r? `@nikomatsakis`

Magic value 3 is used to create state for a yield point. It is in fact
the number of reserved variants.

Lift RESERVED_VARIANTS out to module scope and use it instead.

Rollup of 5 pull requests

Successful merges:

 - #98183 (Fix pretty printing of empty bound lists in where-clause)
 - #98268 (Improve `lifetime arguments are not allowed on` error message)
 - #98273 (Fix minor documentation typo)
 - #98274 (Minor improvements on error for `Self` type in items that don't allow it)
 - #98281 (Fix typo in `HashMap::drain` docs)

Failed merges:

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

Fix typo in `HashMap::drain` docs

It's a map, not a vector.

Fixes #98275.

Minor improvements on error for `Self` type in items that don't allow it

Fixes #93796

Fix minor documentation typo

Fixes incorrect pluralisation of `crate` in documentation for rustc_trait_selection

Improve `lifetime arguments are not allowed on` error message

Actually mention what thing we're improperly trying to add lifetime generics to.

Fix pretty printing of empty bound lists in where-clause

Repro:

```rust
macro_rules! assert_item_stringify {
    ($item:item $expected:literal) => {
        assert_eq!(stringify!($item), $expected);
    };
}

fn main() {
    assert_item_stringify! {
        fn f<'a, T>() where 'a:, T: {}
        "fn f<'a, T>() where 'a:, T: {}"
    }
}
```

Previously this assertion would fail because rustc renders the where-clause as `where 'a, T` which is invalid syntax.

This PR makes the above assertion pass.

This bug also affects `-Zunpretty=expanded`. The intention is for that to emit syntactically valid code, but the buggy output is not valid Rust syntax.

```console
$ rustc <(echo "fn f<'a, T>() where 'a:, T: {}") -Zunpretty=expanded
#![feature(prelude_import)]
#![no_std]
#[prelude_import]
use ::std::prelude::rust_2015::*;
#[macro_use]
extern crate std;
fn f<'a, T>() where 'a, T {}
```

```console
$ rustc <(echo "fn f<'a, T>() where 'a:, T: {}") -Zunpretty=expanded | rustc -
error: expected `:`, found `,`
 --> <anon>:7:23
  |
7 | fn f<'a, T>() where 'a, T {}
  |                       ^ expected `:`
```

It's a map, not a vector.

Make missing argument placeholder more obvious that it's a placeholder

Use `/* ty */` instead of `{ty}`, since people might be misled into thinking that this is valid syntax, and not just a diagnostic placeholder.

Fixes #96880

Addresses Issue 95665 by including `hir::Node::ForeignItem` as a valid
type to visit in `diagnostic_hir_wf_check`.

Fixes #95665

Fix `SourceScope` for `if let` bindings.

Fixes #97799.

I'm not sure how to test this properly, is there any way to observe the difference in behavior apart from `ui` tests? I'm worried that they would be overlooked in the case of a regression.

Incorrect pluralisation of `crate`

Rollup of 4 pull requests

Successful merges:

 - #95534 (Add `core::mem::copy` to complement `core::mem::drop`.)
 - #97912 (Stabilize `Path::try_exists()` and improve doc)
 - #98225 (Make debug_triple depend on target json file content rather than file path)
 - #98257 (Fix typos in `IntoFuture` docs)

Failed merges:

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

Fix typos in `IntoFuture` docs

Make debug_triple depend on target json file content rather than file path

This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation.

This should fix https://github.com/Rust-for-Linux/linux/issues/792 (cc ``@ojeda)``

Stabilize `Path::try_exists()` and improve doc

This stabilizes the `Path::try_exists()` method which returns
`Result<bool, io::Error>` instead of `bool` allowing handling of errors
unrelated to the file not existing. (e.g permission errors)

Along with the stabilization it also:

* Warns that the `exists()` method is error-prone and suggests to use
  the newly stabilized one.
* Suggests it instead of `metadata()` to handle errors.
* Mentions TOCTOU bugs to avoid false assumption that `try_exists()` is
  completely safe fixed version of `exists()`.
* Renames the feature of still-unstable `std::fs::try_exists()` to
  `fs_try_exists` to avoid name conflict.

The tracking issue #83186 remains open to track `fs_try_exists`.

Add `core::mem::copy` to complement `core::mem::drop`.

This is useful for combinators. I didn't add `clone` since you can already
use `Clone::clone` in its place; copy has no such corresponding function.

Make "Assemble stage1 compiler" orders of magnitude faster (take 2)

This used to take upwards of 5 seconds for me locally. I found that the culprit was copying the downloaded LLVM shared object:
```
[22:28:03] Install "/home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/ci-llvm/lib/libLLVM-14-rust-1.62.0-nightly.so" to "/home/jnelson/rust-lang/rust/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib/libLLVM-14-rust-1.62.0-nightly.so"
[22:28:09]   c Sysroot { compiler: Compiler { stage: 1, host: x86_64-unknown-linux-gnu(x86_64-unknown-linux-gnu) } }
```

It turned out that `install()` used full copies unconditionally. Change it to try using a hard-link before falling back to copying.

- Panic if we generate a symbolic link in a tarball
- Change install to use copy internally, like in my previous PR
- Change copy to dereference symbolic links, which avoids the previous regression in #96803.

I also took the liberty of fixing `x dist llvm-tools` to work even if you don't call `x build` previously.