Safety requirements in `core::ptr` disregard type invariants

The only parts of the safety docs of ptr::read that are relevant to references are in the section about ownership.

The exact wording is:

read creates a bitwise copy of T, regardless of whether T is Copy. If T is not Copy, using both the returned value and the value at *src can violate memory safety. Note that assigning to *src counts as a use because it will attempt to drop the value at *src.

Therefore, I believe the following (unsound) function satisfies all safety requirements of read:

fn violate_pin_guarantees<T>(x: std::pin::Pin<Box<T>>) {
    // SAFETY:
    // - The pointer validity requirements are trivially satisfied, as it's created from `&T`
    // - Only the value returned from `read` is used. The original is forgotten.
    let inner: T = unsafe { std::ptr::read(&*x) };
    std::mem::forget(x);
    drop(inner);
}

In general, I believe that the functions in core::ptr are underspecified with respect to type invariants. Raw pointers can be used to bypass privacy and transmute things, yet we don't treat them with the same care as e.g. mem::transmute(_copy) in the docs.

@rustbot label I-unsound T-libs A-docs T-opsem

Start with the linked std::ptr::read documentation, especially the “Ownership of the returned value” section, then compare its safety requirements with the Pin example and the broader concern about core::ptr. Done means the relevant type-invariant and safety requirements are clearly specified in the affected documentation, with the scope of any broader changes decided.