Add a custom builder class for the parser translator

[Earlopain]

I want to be able to add new node types to the parser translator, for example itblock. The bulk of the work is already done by prism itself. In the parser builder, this would be a 5-line change at most but we don't control that here.

Instead, we can add our own builder and either overwrite the few methods we need, or just inline the complete builder. I'm not sure yet which would be better.

rubocop-ast uses its own custom builder for parser. For this to correctly work with RuboCop, it must explicitly choose to extend the prism builder and use it, same as it currently chooses to use a different parser when prism is used: https://github.com/rubocop/rubocop-ast/blob/02b8d0faeeebc3ba6b5284c9e66569bbae836941/lib/rubocop/ast/processed_source.rb#L330

I'd like to enforce that the builder for prism extends its custom one since it will lead to some pretty weird issues when it uses the one from parser otherwise. But first, I'd like to change rubocop-ast to make use of this.

---

It does mean that further node changes when they happen will be decided by prism, and not parser. I also have no good idea yet how it would be tested since currently it only checks against a single ruby version. But these are things to think about after. I think this would definitely be the first step.

@koic, please let me know what you think about this PR and what I've written above.

[Earlopain]

Here's a PR for rubocop-ast showing how it could use this: rubocop/rubocop-ast#354

[bbatsov]

@kddnewton Please, take a look at this when you can, as it's kind of important for RuboCop.

[Earlopain]

Oh, sorry. When I asked in the rubocop issue I was kind of asking for someone from rubocop core to give it an ok (or not)

I asked for koics opinion here so I think it's reasonable that it isn't merged yet since this largely only impacts RuboCop.

[bbatsov]

@Earlopain I did review your suggestion first, and I does make sense to me. 😉

[koic]

I was late in responding, but in reality, this approach seems to be the better one.

Moving forward, there may be cases where node design in Prism::Translation::Parser precedes that of the Parser gem. To ensure compatibility with the Parser gem, which may adopt changes later, it would be beneficial to proactively share node names and other relevant details with the Parser gem developers as needed.

cc @whitequark @iliabylich