Support macro None groupings

[Veykril]

Our macro "model" isn't perfect at handling what macros can actually do, notably we do not parse or handle "None" delimited groups today (rust-lang/rust#67062, notably rustc only partially does as well). It is not really clear what none groups even are supposed to be doing, but its generally agreed (and observable) that they basically work like parentheses in expressions (and presumably the same way in types and pattern positions). In the former, expressions, we currently emit parentheses in some cases to keep parsing precedence, but this is actually quite wrong as proc-macros can observe this difference causing issues for them when they assume a none group. Additionaly, macro fragment captures become none grouped (for the opaque captures at least), something we fail to do as well leading to rust-lang/rust#67062.

In rustc, none groups are handled by encoding them in the parse tree directly, which is easily doable by the fact that expansion expands trees into nodes (replacing the macro call node). Then the parser just has to handle the none groups appropriately. (there are still some problems rustc has here as well, partially cleaned up by rust-lang/rust#124141)

In r-a, things work a bit differently, instead of replacing macro call nodes with their expansion, we keep them, handling the expansion kind of like a virtual syntax tree (virtual in the sense that it does not belong to a file). The main issue here is that we'd need to encode none groups in the syntax tree, but that isn't nicely doable as they could appear wherever in the tree (so we can't just add a new expression kind and the like for it). This is especially annoying when it comes to changing our trivia model #6584, as with that we'd want to have a predictable syntax tree layout which wouldn't be the case with this implemented ... Discarding none groups where they don;'t really do anything is not necessarily possible either, as proc-macros could observe them. So if rustc doesn't do it, we can't really do it either

[ChayimFriedman2]

@Veykril You plan to rewrite our mbe to be more like rustc, no? I imagine this will be easier after.