rustdoc shouldn't render deduced "unimpls" of auto traits as synthetic negative impls but simply not at all

Currently, when a given type doesn't impl an auto trait AutoTrait due to its constituents not impl'ing the auto trait, then rustdoc displays a synthetic negative impl of AutoTrait for said type. However, strictly speaking that's not correct as negative impls affect coherence and SemVer differently.

E.g., for:

pub struct Type(*const ());

rustdoc currently synthesizes

impl !Send for Type

to denote "Type doesn't impl Send" (due to <T: ?Sized> *const T: !Send). However that syntax is clashing with actual negative impls (presently unstably gated under negative_impls) which come with different SemVer guarantees (namely, "the type will never impl Send") and behave differently under coherence (for an example. see #146427).

Since synthetic auto trait impls are meant to be copy/paste-able into the source code w/o it affecting semantics (this principle is violated already, cc https://github.com/rust-lang/rust/issues/111101), the simplest solution would be to stop synthesizing auto trait "unimpls".

I was worried that this isn't quite compatible with conditional negative impls (I might elaborate on that later) but they seem to get rejected anyway (time to update (parts of) #79098) with E0367. In any case, we might someday also have impl ?Trait for Type (Negative impls draft RFC § ? and auto-traits, https://github.com/rust-lang/rust/issues/68318#issuecomment-1832748878 et seqq.) which we could fall back to in case we ever need to express more complex bounds.

Originally reported in https://github.com/rust-lang/rust/issues/146427#issuecomment-3290129137 by @RReverser.