Support forwarding flags on scopes

[kddnewton]

When parent scopes around an eval are forwarding parameters (like *, **, &, or ...) we need to know that information when we are in the parser. As such, we need to support passing that information into the scopes option. In order to do this, unfortunately we need a bunch of changes.

The scopes option was previously an array of array of strings. These corresponded to the names of the locals in the parent scopes. We still support this, but now additionally support passing in a Prism::Scope instance at each index in the array. This Prism::Scope class holds both the names of the locals as well as an array of forwarding parameter names (symbols corresponding to the forwarding parameters). There is convenience function on the Prism module that creates a Prism::Scope object using Prism.scope.

In JavaScript, we now additionally support an object much the same as the Ruby side. In Java, we now have a ParsingOptions.Scope class that holds that information. In the dump APIs, these objects in all 3 languages will add an additional byte for the forwarding flags in the middle of the scopes serialization.

All of this is in service of properly parsing the following code:

def foo(*) = eval("bar(*)")

[eregon]

One thought: what if for simplicity we kept the existing structure (an array of array of strings) and represented that new information by simply adding *, **, &, or ... in those arrays, as "pseudo locals"?
Usages might even choose easily that way if they want to represent those as locals (a valid choice) or something more complicated.

[kddnewton]

One thought: what if for simplicity we kept the existing structure (an array of array of strings) and represented that new information by simply adding *, **, &, or ... in those arrays, as "pseudo locals"? Usages might even choose easily that way if they want to represent those as locals (a valid choice) or something more complicated.

It ends up being much easier to represent them separately since the then the size of the locals matches up with the size of the locals table, and you know it beforehand so you can allocate the a fixed size array.

[eregon]

I see, now that #3410 (comment) is clarified I think this approach is good.
I guess CRuby needs some possibly-hidden locals for */**/&/..., but those can then be easily added based on the flags (and might not be 1-1).
There might be some temporary locals too for things like flip-flops which are then added later but that's probably rare, most temp locals are probably just stack slots.
FWIW on TruffleRuby there are quite a few temp locals (at least currently) so predicating the local table size is not that useful.