Relax the generic requirements for `NoUninit` and `CheckedBitPattern` derives.

[stegaBOB]

For NoUninit, if the struct itself is #[repr(packed)] with align 1 and the generic is also NoUninit, I believe it should be safe to derive since there shouldn't be any padding bytes and the rest of the checks should run for the the remaining fields in the derive macro. I would be happy to add this change if I'm not overlooking something.

As for CheckedBitPattern, I'm not entirely sure if there is some specific reason why generics aren't supported. From my understanding there's nothing in the trait that inherently prevents something like this. I would be happy to attempt a macro change for this as well.

[Lokathor]

I believe that this simply hasn't been added yet, and that it would be sound for someone to add it in.

[kpreid]

A quirk, arguably a bug: the Pod derive accepts such a packed struct (as of 1.21.0) even though NoUninit does not.

#[repr(C, packed)]
#[derive(Clone, Copy, bytemuck::Pod, bytemuck::Zeroable)]
struct Succeeds<T> {
    a: T,
    b: T,
}

#[repr(C, packed)]
#[derive(Clone, Copy, bytemuck::NoUninit)]
struct Fails<T> {
    a: T,
    b: T,
}