Standardize whether T: KnownLayout requires T's fields to be KnownLayout

[joshlf]

Progress

• Restrict KnownLayout for Unalign<T> to require T: KnownLayout (add a test to confirm this behavior doesn't regress)
  • Record the fact that the reason for doing it this way (rather than always implementing it manually - even when feature = "derive" - without a T: KnownLayout bound) is to be forwards-compatible with supporting unsized Unalign (#209)
• Teach impl_or_verify! to support KnownLayout - the Unalign bounds issue wasn't caught because, for KnownLayout, we use impl_known_layout! rather than impl_or_verify!
• [Possibly after 0.8] Relax so that T: KnownLayout never requires its fields to be KnownLayout

Details

Relates to #29.

Consider the following code:

#[derive(KnownLayout]
#[repr(C)]
pub struct Foo<T>(T);

Since T has an implicit T: Sized bound, our emitted derive should not require that T: KnownLayout, but it does. This is currently affecting Unalign, resulting in it having a different bound when compiling with feature = "derive" (namely, T: KnownLayout) than when compiling without feature = "derive".

[jswrenn]

In discussion with @joshlf, we decided to make the KnownLayout requirement recursive. Our reasoning for this is that all of our other traits have recursive requirements, so users are unlikely to find themselves in a situation where the recursive requirement of, say, FromBytes can be satisfied but KnownLayout cannot.

[joshlf]

In a discussion with @jswrenn and @djkoloski, we decided:

• Based on this comment, we won't have any use for T: KnownLayout to require T's fields to be KnownLayout
• It is unlikely that we will want to support unsized Unalign
• So long as Unalign is always Sized, we can unconditionally manually implement KnownLayout for Unalign<T> even when T: ?KnownLayout, and not conditional on feature = "derive"