…ls` (#23957)

Move work from `#[ast]` macro into `ast_tools`. Calculate whether an enum is fieldless or not in `ast_tools` and pass that info to `#[ast]` macro via an `EnumDetails` struct. This avoids having to iterate over all variants of each enum in the macro.

This is preferable because `ast_tools` runs only after changes to AST, whereas the macro code runs every time `oxc_ast` crate is compiled.

…#23958)

Similar to #23957.

Move work from `#[ast]` macro into `ast_tools`. Calculate whether a struct can be marked `#[repr(transparent)]` or not in `ast_tools` and pass that info to `#[ast]` macro via the `StructDetails` struct. This has 2 advantages:

1. Avoids having to iterate over all fields of each struct in the macro.
2. It's more accurate. `ast_tools` knows the size of fields, so it can exclude ZST fields from the count.

A struct like this will now be marked `#[repr(transparent)]` despite having more than 1 field, because 2 of the fields contain ZSTs:

```rust
struct Foo<'a> {
    num: u32,
    _align: [usize; 0],
    _marker: PhantomData<&'a ()>,
}
```

Moving work from macro into `ast_tools` is preferable because `ast_tools` runs only after changes to AST, whereas the macro code runs every time `oxc_ast` crate is compiled.

…#23958)

Similar to #23957.

Move work from `#[ast]` macro into `ast_tools`. Calculate whether a struct can be marked `#[repr(transparent)]` or not in `ast_tools` and pass that info to `#[ast]` macro via the `StructDetails` struct. This has 2 advantages:

1. Avoids having to iterate over all fields of each struct in the macro.
2. It's more accurate. `ast_tools` knows the size of fields, so it can exclude ZST fields from the count.

A struct like this will now be marked `#[repr(transparent)]` despite having more than 1 field, because 2 of the fields contain ZSTs:

```rust
struct Foo<'a> {
    num: u32,
    _empty: [u8; 0],
    _marker: PhantomData<&'a ()>,
}
```

Moving work from macro into `ast_tools` is preferable because `ast_tools` runs only after changes to AST, whereas the macro code runs every time `oxc_ast` crate is compiled.

…ls` (#23957)

Move work from `#[ast]` macro into `ast_tools`. Calculate whether an enum is fieldless or not in `ast_tools` and pass that info to `#[ast]` macro via an `EnumDetails` struct. This avoids having to iterate over all variants of each enum in the macro.

This is preferable because `ast_tools` runs only after changes to AST, whereas the macro code runs every time `oxc_ast` crate is compiled.

…#23958)

Similar to #23957.

Move work from `#[ast]` macro into `ast_tools`. Calculate whether a struct can be marked `#[repr(transparent)]` or not in `ast_tools` and pass that info to `#[ast]` macro via the `StructDetails` struct. This has 2 advantages:

1. Avoids having to iterate over all fields of each struct in the macro.
2. It's more accurate. `ast_tools` knows the size of fields, so it can exclude ZST fields from the count.

A struct like this will now be marked `#[repr(transparent)]` despite having more than 1 field, because 2 of the fields contain ZSTs:

```rust
struct Foo<'a> {
    num: u32,
    _empty: [u8; 0],
    _marker: PhantomData<&'a ()>,
}
```

Moving work from macro into `ast_tools` is preferable because `ast_tools` runs only after changes to AST, whereas the macro code runs every time `oxc_ast` crate is compiled.