These test can fail on stage 1

The thumbv6m target does not support atomics. Historically, LLVM
had a bug where atomic load/stores for this target were emitted
as plain load/stores rather than as libatomic calls. This was
fixed in https://reviews.llvm.org/D120026, which will be part of
LLVM 15. As we require that "atomic support" does not use libatomic,
we need to indicate that this target does not have native atomics.

…r=Mark-Simulacrum

Make `ui-fulldeps/gated-plugins` and `ui-fulldeps/multiple-plugins` tests stage 2 only

These test can fail on stage 1.

Fixes rust-lang#99295

…rk-Simulacrum

Add some additional double-adjustment regression tests

I accidentally missed these when I rebased rust-lang#98785

cc rust-lang#98894 and rust-lang#98897

…-item, r=lcnr

Do not resolve associated const when there is no provided value

Fixes rust-lang#98629, since now we just delay a bug when we're not able to evaluate a const item due to the value not actually being provided by anything. This means compilation proceeds forward to where the "missing item in impl" error is emitted.

----

The root issue here is that when we're looking for the defining `LeafDef` in `resolve_associated_item`, we end up getting the trait's AssocItem instead of the impl's AssocItem (which does not exist). This resolution "succeeds" even if the trait's item has no default value, and then since this item has no value to evaluate, it turns into a const eval error.

This root issue becomes problematic (as in rust-lang#98629) when this const eval error happens in wfcheck (for example, due to normalizing the param-env of something that references this const). Since this happens sooner than the check that an impl actually provides all of the items that a trait requires (which happens during later typecheck), we end up aborting compilation early with only this un-informative message.

I'm not exactly sure _why_ this bug arises due to rust-lang#96591 -- perhaps valtrees are evaluated more eagerly than in the old system?

r? ``@oli-obk`` or ``@lcnr`` since y'all are familiar with const eval and reviewed rust-lang#96591, though feel free to reassign.

This is a regression from stable to beta, so I would be open to considering this for beta backport. It seems correct to me, especially given the improvements in the other UI tests this PR touches, but may have some side-effects that I'm unaware of...?

Mark atomics as unsupported on thumbv6m

The thumbv6m target does not support atomics. Historically, LLVM
had a bug where atomic load/stores for this target were emitted
as plain load/stores rather than as libatomic calls. This was
fixed in https://reviews.llvm.org/D120026, which will be part of
LLVM 15. As we require that "atomic support" does not use libatomic,
we need to indicate that this target does not have native atomics.

Lock stdout once when listing tests

This is a marginal optimization for normal operation, but for `cargo miri nextest list` (which is invoked by `cargo miri nextest run`) this knocks the startup time on `regex` down from 87 seconds to 17 seconds. Still slow, but a nice 5x improvement.

…triddle

Remove Clean trait implementation for hir::Ty and middle::Ty

While going through the code, I realized that the "remove the Clean trait" effort which was started a while ago was never finished.

The idea behind it was to make it much simpler to go through the different clean steps (which is definitely not easy when you just have `something.clean(cx)`).

I'm planning to finish this effort.

cc ``@camelid``
r? ``@notriddle``