Use a proc macro for generating Rust code from GLL grammars.

[eddyb]

At least it should be one of the provided options, alongside separate code generation.

---

A huge benefit is being able to use Spans from the grammar syntax, inside the generated code.

Given rust-lang/rust#51980, breakpoints should be possible at a given line + column, assuming debuggers support them (sadly, that PR left columns disabled windows).

We could them be putting breakpoints and stepping through grammar rules, in whatever syntax variant they were specified by the user!

By strategically naming some variables to e.g. input, we can also make debuggers able to show the currently remaining input to parse, potentially at zero cost to the implementation.
(But showing "current input line/column", without on-demand computation, would incur a penalty).

EDIT: @eternaleye points out that breadth-first is not ideal for debugging. We could have depth-first as part of a "debug mode", or just separately toggleable (even at runtime; not sure if "free" though).

[eddyb]

One issue is figuring out how the terminals are actually encoded - if we do strings, who tokenizes/lowers the strings into something that can match the input?
cc @Centril

EDIT: resolved, for now, by hardcoding proc_macro tokens as an option, and using Pat: From<scannerless::Pat> for the tokenziation/lowering.

[est31]

sadly, that PR left columns disabled windows

FYI, it's because of Visual Studio expecting debug info to either only contain line number, or a full (start line, start column, end line, end column) span range, otherwise it's buggy: rust-lang/rust#42921 (comment)

This information is present in rustc already. However at least back when I made the PR, there was no LLVM support for range based spans.