Update NonNull::align_offset quarantees, keeping it in sync with ptr::align_offset

…k-nonnull-alignoffset-update, r=Amanieu

Update NonNull::align_offset quarantees

This PR proposes to update [`NonNull::align_offset`](https://doc.rust-lang.org/stable/std/ptr/struct.NonNull.html#method.align_offset) guarantees, which should to be matched with [`ptr::align_offset`](https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.align_offset-1)
(as `NonNull::align_offset` delegates to `ptr::align_offset`).

[PR rust-lang#121201](rust-lang#121201) updated only `ptr::align_offset` docs.

…ir, r=davidtwco

Make `validate_mir` ensure the final MIR for all bodies

A lot of the crashes tests use `-Zpolymorphize` or `-Zdump-mir` for their side effect of computing the `optimized_mir` for all bodies, which will uncover bugs with late MIR passes like the inliner. I don't like having all these tests depend on `-Zpolymorphize` (or other hacky ways) for no reason, so this PR extends the `-Zvalidate-mir` flag to ensure `optimized_mir`/`mir_for_ctfe` for all body owners during the analysis phase.

Two thoughts:
1. This could be moved later in the compilation pipeline I guess? I don't really think it matters, though.
1. This could alternatively be expressed using a new flag, though I don't necessarily see much value in separating these.

For example, rust-lang#128171 could have used this flag, in the `tests/ui/polymorphization/inline-incorrect-early-bound.rs`.

r? mir

Add regression test

Fixes rust-lang#125873

…=lcnr

Don't implement `AsyncFn` for `FnDef`/`FnPtr` that wouldnt implement `Fn`

Due to unsafety, ABI, or the presence of target features, some `FnDef`/`FnPtr` types don't implement `Fn*`. Do the same for `AsyncFn*`.

Noticed this due to rust-lang#128764, but this isn't really related to that ICE, which is fixed in rust-lang#128792.

… r=jieyouxu

Update E0517 message to reflect RFC 2195.

E0517 occurs when a `#[repr(..)]` attribute is placed on an unsupported item. Currently, the explanation of the error implies that `#[repr(u*/i*)]` cannot be placed on fieldful enums, which is no longer the case since [RFC 2195](rust-lang/rfcs#2195) was [stabilized](rust-lang#60553), which allows placing `#[repr(u*/i*)]` and/or `#[repr(C)]` on fieldful enums to produce a defined layout.

This PR doesn't (currently) add a description of the semantics of placing `#[repr(u*/i*)]` on a fieldful enum to the error explanation, it just removes the claims/implications that it is not allowed.

…petrochenkov

rm `declared_features` field in resolver

r? `@petrochenkov`

…s, r=compiler-errors

Only suggest `#[allow]` for `--warn` and `--deny` lint level flags

`--force-warn` and `--forbid` cannot be overridden