…tAddrV6`

The following methods are made unstable const under the `const_socketaddr` feature:

`SocketAddr`
 - `ip`
 - `port`
 - `is_ipv4`
 - `is_ipv6`

`SocketAddrV4`
 - `ip`
 - `port`

`SocketAddrV6`
 - `ip`
 - `port`
 - `flowinfo`
 - `scope_id`

This cuts the time to run the tests in half, because they don't require
building a stage 2 compiler.

This doesn't change coverage tests, which will be changed soon in a
separate PR.

These are currently documented in the API guidelines:

https://rust-lang.github.io/api-guidelines/interoperability.html#error-types-are-meaningful-and-well-behaved-c-good-err

I think it makes sense to uplift this guideline (in a milder form) into
std docs. Printing and producing errors is something that even
non-expert users do frequently, so it is useful to give at least some
indication of what a typical error message looks like.

Only public items are monomorphization roots. This can be confirmed by noting that this program compiles:
```rust
fn foo<T>() { if true { foo::<Option<T>>() } }
fn bar() { foo::<()>() }
```

This commit adds an additional target property – `supported_sanitizers`,
and replaces the hardcoded allowlists in argument parsing to use this
new property.

Fixes rust-lang#81802

…get-prop, r=tmiasko

Maintain supported sanitizers as a target property

In an effort to remove a hard-coded allow-list for target-sanitizer support correspondence, this PR moves the configuration to the target options.

Perhaps the one notable change made in this PR is this doc-comment:

```rust
    /// The sanitizers supported by this target
    ///
    /// Note that the support here is at a codegen level. If the machine code with sanitizer
    /// enabled can generated on this target, but the necessary supporting libraries are not
    /// distributed with the target, the sanitizer should still appear in this list for the target.
```

Previously the target would typically be added to the allow-list at the same time as the supporting runtime libraries are shipped for the target. However whether we ship the runtime libraries or not needn't be baked into the compiler; and if we don't users will receive a significantly more directed error about library not being found.

Fixes rust-lang#81802

Constify methods of `std::net::SocketAddr`, `SocketAddrV4` and `SocketAddrV6`

The following methods are made unstable const under the `const_socketaddr` feature (rust-lang#82485):

```rust
// std::net

impl SocketAddr {
    pub const fn ip(&self) -> IpAddr;
    pub const fn port(&self) -> u16;
    pub const fn is_ipv4(&self) -> bool;
    pub const fn is_ipv6(&self) -> bool;
}

impl SocketAddrV4 {
    pub const fn ip(&self) -> IpAddr;
    pub const fn port(&self) -> u16;
}

impl SocketAddrV6 {
    pub const fn ip(&self) -> IpAddr;
    pub const fn port(&self) -> u16;
    pub const fn flowinfo(&self) -> u32;
    pub const fn scope_id(&self) -> u32;
}
```

Note: `SocketAddrV4::ip` and `SocketAddrV6::ip` use pointer casting and depend on the unstable feature `const_raw_ptr_deref`

Avoid sorting by DefId for `necessary_variants()`

Follow-up to rust-lang#83074. Originally I tried removing `impl Ord for DefId` but that hit *lots* of errors 😅 so I thought I would start with easy things.

I am not sure whether this could actually cause invalid query results, but this is used from `MarkSymbolVisitor::visit_arm` so it's at least feasible.

r? `@Aaron1011`

Move rustdoc run-make-fulldeps tests to run-make

This cuts the time to run the tests in half, because they don't require
building a stage 2 compiler. They were all added to fulldeps before rust-lang#82802 because rustdoc wasn't available in run-make tests.

This doesn't change coverage tests, which will be changed soon in a
separate PR (rust-lang#83755 (comment)).

This also changes some of the `-include` directives, see rust-lang#83773 for what's going on there.

r? `@petrochenkov`

Document "standard" conventions for error messages

These are currently documented in the API guidelines:

https://rust-lang.github.io/api-guidelines/interoperability.html#error-types-are-meaningful-and-well-behaved-c-good-err

I think it makes sense to uplift this guideline (in a milder form) into
std docs. Printing and producing errors is something that even
non-expert users do frequently, so it is useful to give at least some
indication of what a typical error message looks like.

Monomorphization doc fix

Only public items are monomorphization roots. This can be confirmed by noting that this program compiles:
```rust
fn foo<T>() { if true { foo::<Option<T>>() } }
fn bar() { foo::<()>() }
```
See also the [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Why.20are.20non.20public.20items.20monomorphization.20roots.3F).