Parse MacroVar with empty expressions: %var{}

[straight-shoota]

Fixes the parser choking on %var{} in a macro context.

It might be debatable whether a macro var with empty expressions should be valid syntax. It doesn't make much sense semantically. But I don't see a good reason why it shouldn't.

Similar to #16741, this seems like an omission. Any number of expressions should be acceptable, including zero.

[oprypin]

This change effectively introduces new valid syntax so maybe it's worth a slightly deeper discussion.

Maybe it's best to turn it into an explicit error instead? I wouldn't call it a necessary generalization because %var is already the generalization, and this is duplicate syntax for it. I think it can only bring confusion to the reader, and doesn't satisfy any new use case.

I think there were some issues solved long ago where splatting of 0 arguments inside macros was made to work, and it was necessary because the input could be any number of args. But this is not like that, there's no way to use this syntax in a programmatic way

[straight-shoota]

Even if there is no programmatic way to produce this syntax, it could still appear when rewriting code.

The syntax is pretty unambiguous. What else could %var{} possibly be interpreted as?
So I'd rather allow the syntax than make it an error.
And we should rewrite to drop the braces in the formatter. Forgot to add that bit in this PR.
We can't change this in the formatter easily because it might produce invalid code: macro foo;%var{}end becomes macro foo;%varend. So the current state of this PR should be fine.

[ysbaddaden]

I'm fine with either a proper parser error or accepting the syntax.

[ysbaddaden]

@straight-shoota the assertion from #16778 is now failing.