Resolve visiblity restrictions imposed by the `#[generate_derive(...)]` macro.

The one thing that could confuse people is visibility. We're used to code generated by #[derive] sitting next to the struct/enum it's derived on, and having access to everything you can "see" from that position. Obviously #[generated_derive] doesn't work like that.

I don't think much we can do about that, but we should document that you have to make structs/enums/fields pub(crate) if you're using #[generated_derive], so people at least understand how to use it.

Or (and very possibly this is a stupid idea), could we make it work like #[derive]? e.g.:

• Generate 1 file of generated code for each source file (not one for each crate).
• Introduce a #[derive_generator] macro.

Then you use #[generated_derive] as follows:

// src/foo.rs
#[derive_generator]
use oxc_allocator::CloneIn;

#[generated_derive(CloneIn)]
struct Foo { // Not pub
    blah: u64 // Not pub
}

#[derive_generator] would expand to:

include!("generated/derive_clonein_foo.rs");

Then the generated code has access to everything in the source file without having to make anything pub (still wouldn't work for a struct which is defined inside a private module {} block, but that's a niche case).

This approach has pluses and minuses... maybe it solves one problem but creates another!

Originally posted by @overlookmotel in https://github.com/oxc-project/oxc/issues/5278#issuecomment-2322174286

Start by reading the visibility discussion around #[generated_derive] and the example paths src/foo.rs and generated/derive_clonein_foo.rs. Determine whether the issue should document the pub(crate) requirement or pursue the proposed source-file generation approach. Done means the visibility behavior and supported usage are clearly documented, with any design decision recorded.