Add new trait impls

[joshlf]

Add the following impls:

• str: Unaligned
• NonZeroU8: Unaligned
• NonZeroI8: Unaligned
• Option<NonZeroU8>: Unaligned
• Option<NonZeroI8>: Unaligned
• MaybeUninit<T>: Unaligned where T: Unaligned

Previously, unsafe_impl! special-cased Unaligned and emitted a static assertion that the type in question actually had alignment 1. Since this used core::mem::align_of, which only works for Sized types, it was incompatible with adding an impl of Unaligned for str in this commit. In order to avoid this issue, this commit removes that special-casing, and introduces a new assert_unaligned! macro. Existing Unaligned implementations are modified to also call assert_unaligned!. assert_unaligned!(str) is not used since str: !Unaligned.

[joshlf]

@djkoloski you may have thoughts here. I don't yet have safety comments for NonZeroX8: Unaligned or Option<NonZeroX8>: Unaligned, and my plan is to wait for rust-lang/rust#104082 to merge and then cite the updated documentation and then merge this PR at that point. However, if you can think of a different way to justify the soundness of those impls today (we can leave a TODO comment to cite the documentation once that PR lands), that'd be awesome.

[djkoloski]

Maybe you could argue that since Option<NonZeroU8> and Option<NonZeroI8> are both guaranteed to be the same size as u8 and i8, that they must be the same size or smaller and so must have size 1. A size of 1 also implies an align of 1 since size must be a multiple of align.

[joshlf]

Maybe you could argue that since Option<NonZeroU8> and Option<NonZeroI8> are both guaranteed to be the same size as u8 and i8, that they must be the same size or smaller and so must have size 1. A size of 1 also implies an align of 1 since size must be a multiple of align.

I was on the fence about taking that approach, but thinking about it more (and reinforced by you suggesting the same), I guess it's basically unthinkable that they would ever change that aspect of the layout of those types. I was thinking that the wording in that documentation is sufficiently weak (it says "is", not "is guaranteed to be" or something similar - it reads as though it could just be saying "in practice"), but I think that's probably not enough of a concern to block this. I'll go with that approach.

[joshlf]

OK done! Ready for review whenever you get a chance.