False positive derive error for `TransparentWrapper` around types like `Box`

[cbarrick]

It appears that the derive macro for TransparentWrapper does not work with types like Box or Option.

I'm not sure if this is a bug or a feature request.

Minimal repro:

extern crate bytemuck; // 1.14.0

use core::marker::PhantomData;

#[derive(bytemuck::TransparentWrapper)]
#[transparent(Box<usize>)]
#[repr(transparent)]
pub struct Foo {
    data: Box<usize>,
    marker: PhantomData<()>,
}

Expected reslut:

Foo: TransparentWrapper<Box<usize>>

Actual result:

error: TransparentWrapper must have one field of the wrapped type
 --> src/lib.rs:5:10
  |
5 | #[derive(bytemuck::TransparentWrapper)]
  |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: this error originates in the derive macro `bytemuck::TransparentWrapper` (in Nightly builds, run with -Z macro-backtrace for more info)

[Lokathor]

In general, I don't really work on the proc-macros parts of the crate myself, so I don't know for sure, but https://github.com/Lokathor/bytemuck/blob/main/derive/src/traits.rs#L259 seems to be the code that decides what the wrapped type is when an argument is given. At a glance, it looks like the code will only pull one token from the stream iterator (which is assumed to be the type's ident), so it won't work with any types that use a generic (which looks like name < t >, four tokens).

This is not by design, it should work with generics, and I'd be happy to accept a PR that fixes this situation.