Review potential implementors for `TransparentWrapper`

[HeroicKatora]

The library itself provides no implementors for the trait trait. This is odd as there are several transparent wrappers within the standard library. Some of them might be valid, some less so.

• core::mem::ManuallyDrop<T>
• core::num::Wrapping

Invalid ones:

• core::cell::Cell: This would allow turning a &T into a &Cell<T> and subsequently write to memory that was assumed to be read-only. But Cell::from_mut exists and so a purely mutable variant would be valid. Unclear about the wrapping of niches.
• core::mem::MaybeUninit: Would allow writing uninitialized memory to the referree. Here only a non-mutable variant would be valid. Unclear about the wrapping of niches.
• core::pin::Pin: This basically constructs a Pin and would thus violate some of its safety assumptions of the unsafe constructor. However, it might be possible to gate such an impl with the same bounds as Pin::new. There is no way for a purely mutable or immutable variant that does not adhere to the same rules as even cloning the Pin is a safety critical operation.
• core::task::Waker: Another example of a type that is unsafe to construct.

Unclear:

• core::cell::UnsafeCell: Highly dubious for the reasons of Cell. But itself it does not expose any safe method for writing so it is arguably a pure wrapper on its own that only affects the languages treatment of references and pointers (in stacked borrowed) themselves. Unclear about the wrapping of niches.
• std::io::IoSlice{,Mut}: This is actually a transparent wrapper around a target dependent underlying type such as libc::iovec on unix.

[HeroicKatora]

This poses another question: Is the trait's description actually precise enough to explain the valid and invalid uses above?

[HeroicKatora]

One more unclear implementation (this SemVer is compatible, right?):

impl<T, U> TransparentWrapper<[U]> for [T]
    where T: TransparentWrapper<U>
{ }

An alternative would be to introduce this as a pair of methods instead.