Inline the (Yul)Statement parser in v0/v1

[Xanewok]

Part of #652

Seems convenient for the AST/CST (to not need to unwrap another layer) but we lose the ability to test it as a named parser and the generated parser code gets a bit bloated, since we now inline the choice.

Maybe it'd be better if we somehow allow to "outline" select enums in v2, like this one? @OmarTawfik

[changeset-bot]

⚠️ No Changeset found

Latest commit: 3510c00

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[OmarTawfik]

This side effect is also true for Precedence items, and for the same reason, since now they always result in a unique node (an operator expression, or a primary expression), they don't have to produce their own top-level nodes. From the design doc:

It is important to note that the item name doesn't contribute a NonTerminalKind, but each PrecedenceExpression under it contributes one.

[Xanewok]

Could you elaborate a bit which side effect are you referring to here?

[OmarTawfik]

I was commenting on:

Maybe it'd be better if we somehow allow to "outline" select enums in v2, like this one? @OmarTawfik

Are you suggesting this just for testing? I think I will have to introduce strongly typed parseEnumFoo() -> EnumFoo at some point anyways. We can test its root node, even if it wasn't wrapped with an explicit NonTerminalKind. Thoughts?

I was also mentioning that like Enum items, Precedence items also don't produce their own NonTerminalKind, but their inner precedence_expressions entries do.

[Xanewok]

Right, I wanted to specifically say that being able to parse a general construct like "expression" or "statement" seems like something we want to do anyway, even if it doesn't have a dedicated rule kind in the CST (is inlined), so the future parseEnum approach answers my concern.