Do not assemble candidates for default impls

There is no reason (as far as I can tell?) that we should assemble an impl candidate for a default impl. This candidate itself does not prove that the impl holds, and any time that it *does* hold, there will be a more specializing non-default impl that also is assembled.

This is because `default impl<T> Foo for T {}` actually expands to `impl<T> Foo for T where T: Foo {}`. The only way to satisfy that where clause (without coinduction) is via *another* implementation that does hold -- precisely an impl that specializes it.

This should fix the specialization related regressions for rust-lang#116494. That should lead to one root crate regression that doesn't have to do with specialization, which I think we can regress.

r? lcnr cc `@rust-lang/types`

cc rust-lang#31844

…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#118882 (Check normalized call signature for WF in mir typeck)
 - rust-lang#120999 (rustdoc: replace `clean::InstantiationParam` with `clean::GenericArg`)
 - rust-lang#121002 (remove unnecessary calls to `commit_if_ok`)
 - rust-lang#121005 (Remove jsha from the rustdoc review rotation)
 - rust-lang#121043 (add lcnr to the compiler-team assignment group)
 - rust-lang#121045 (Fix two UI tests with incorrect directive / invalid revision)
 - rust-lang#121046 (Fix incorrect use of `compile_fail`)
 - rust-lang#121047 (Do not assemble candidates for default impls)

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

Rollup merge of rust-lang#121047 - compiler-errors:default-impls, r=lcnr

Do not assemble candidates for default impls

There is no reason (as far as I can tell?) that we should assemble an impl candidate for a default impl. This candidate itself does not prove that the impl holds, and any time that it *does* hold, there will be a more specializing non-default impl that also is assembled.

This is because `default impl<T> Foo for T {}` actually expands to `impl<T> Foo for T where T: Foo {}`. The only way to satisfy that where clause (without coinduction) is via *another* implementation that does hold -- precisely an impl that specializes it.

This should fix the specialization related regressions for rust-lang#116494. That should lead to one root crate regression that doesn't have to do with specialization, which I think we can regress.

r? lcnr cc ``@rust-lang/types``

cc rust-lang#31844