Rollup merge of #140638 - RalfJung:unsafe-pinned-shared-aliased, r=workingjubilee

UnsafePinned: also include the effects of UnsafeCell

This tackles rust-lang/rust#137750 by including an `UnsafeCell` in `UnsafePinned`, thus imbuing it with all the usual properties of interior mutability (no `noalias` nor `dereferenceable` on shared refs, special treatment by Miri's aliasing model). The soundness issue is not fixed yet because coroutine lowering does not use `UnsafePinned`.

The RFC said that `UnsafePinned` would not permit mutability on shared references, but since then, rust-lang/rust#137750 has demonstrated that this is not tenable. In the face of those examples, I propose that we do the "obvious" thing and permit shared mutable state inside `UnsafePinned`. This seems loosely consistent with the fact that we allow going from `Pin<&mut T>` to `&T` (where the former can be aliased with other pointers that perform mutation, and hence the same goes for the latter) -- but the `as_ref` example shows that we in fact would need to add this `UnsafeCell` even if we didn't have a safe conversion to `&T`, since for the compiler and Miri, `&T` and `Pin<&T>` are basically the same type.

To make this possible, I had to remove the `Copy` and `Clone` impls for `UnsafePinned`.

Tracking issue: rust-lang/rust#125735
Cc ``@rust-lang/lang`` ``@rust-lang/opsem``  ``@Sky9x``
I don't think this needs FCP since the type is still unstable -- we'll finally decide whether we like this approach when `UnsafePinned` is moved towards stabilization (IOW, this PR is reversible). However, I'd still like to make sure that the lang team is okay with the direction I am proposing here.

Author: matthiaskrgr