Expose AST tools as a public crate?

@rzvxa suggested in a Discord conversation that we might want to consider exposing AST codegen as a public crate, so that consumers of Oxc can generate code for acting on AST that's specific to their use case, but would be laborious to write by hand.

My opinion is:

1. AST codegen is a very powerful tool, and it may well be a good idea to expose it at some point.
2. We may not want to do that right now. We don't need to expose it, and as it's fairly new, we may have some API changes to make yet.

If/when we do, I think we'd need to break it up into multiple crates/tasks, along these kind of lines:

• Task 1 contains:
  • Code to parse source .rs files and generate the schema (which would include calculating field re-ordering, so offsets in the schema are the final ones).
• Public crate contains:
  • The schema (as generated by Task 1).
  • Generator types.
  • Functions to run a generator on the schema and produce the generated output.
• Task 2:
  • Depends on the public crate.
  • Contains our own collection of generators which we run to generate Visit, CloneIn etc.

I think this is quite a nice separation of concerns, so not such a bad idea. But it would require major refactoring of the codegen (again!), so maybe that's another reason not to do this right now.

Open question: I'm not sure how we'd deal with it if we only do field re-ordering in release mode (due to the Rust Analyser problem). Do we have to generate two schemas for debug mode and release mode?

No files or tests are named. Start by locating the existing AST codegen and schema-generation work, then examine how field re-ordering differs between debug and release mode. Done would require an agreed public-crate and task split, including the schema, generators, and downstream Visit and CloneIn generation.