Avoid the `insert!` macro in AST codegen. Use doc comments starting with special symbol `@` instead.
* Before: `insert!("// plain comment");`
* After: `///@ plain comment`
* Or: `//!@ plain comment`
Either `///@` or `//!@` is converted to plain `//` in output.
`//!@` is legal in top-of-file position, which allows us to inline `#![allow(...)]` attributes, which in my opinion makes the generators a bit easier to read.
Remove `Generator::name` and `Pass::name` methods. All impls for these methods return a string identical to the struct name, so can set return value of `Runner::name` in `define_generator!` and `define_pass!` macros instead.
This PR introduces `EarlyCtx` and `LateCtx` in place of the old `CodegenCtx`, Early passes operate at the AST level while generators and other late passes operate on the schema.
It will also replace the confusing `RType` name with something more idiomatic ~~(open for suggestions, I haven't found a good name yet)~~ I've named it `AstType` and dropped the `R` prefix for `REnum` and `RStruct`.
There are some qualities of life improvements too, Things like `to_type_elide` can be used to simplify the code.
Related to #4442 (and can potentially mark it "close as fixed").
~~The generated code is only here for the sake of my own comparison (instead of manually keeping a backup of the old generated file). I would clean this up as soon as it is ready, submit some parts of it as the down stack, and stack the actual generated code on top of this. So please don't let the huge diff distract you, It won't have many conflicts since almost all of these are the generated visit code, which is completely contained to its own module(other than some minor renaming refactors).~~
The order of function definitions is a bit different, I've used a depth-first search, We can switch to a breadth-first one to align functions more closely to the original.
We use prettyplease for formatting our generated code, Which has a lot of advantages over rustfmt, But sometimes it conflicts with our cargo fmt config,
Since it isn't configurable I just added a `cargo fmt` step after the generation process to prevent conflicts.
We might be able to not rely on prettyplease at all, But We have to test that one after we have most of our generated code, rustfmt usually bails on nested calls and macros so it might not work as our only solution. In contrast to that prettyplease is used in both bindgen and cargo-expand and is created for this exact reason(formatting generated code).
