Fix and optimize arguments handling

[marcandre]

When looking at some cops' performance I realized that #arguments? seemed to take non-negligible time. I realized that it creates an array, only to later check if it's empty. This PR optimizes this, for SendNode and others like it (modern mode only).

SuperNode, DefinedNode and YieldNode were worse, in that two temporary arrays were created for each argument call (including #arguments?) and are also (trivially) optimized.

This fixes LambdaNode (modern only) for arguments and #receiver

[bbatsov]

I don't quite get the "trail" terminology.

[marcandre]

The first few children are not the arguments, only the trailing ones are.
I don't like ParameterizedNode, and I dislike ParameterizedTrailNode even more 😅, but I'm severly uninspired. Suggestions?

[marcandre]

@bbatsov is TrailingArgumentsNode a better name?

[marcandre]

ping @bbatsov

[Drenmi]

It gets a bit hairy, I guess, because the naming of the other nodes make reference to Ruby and its syntax, while this is a reference to the Parser output.

[marcandre]

@Drenmi right, but there is still shared handling of the AST like in WrappedArgumentsNode (that isn't just an optimization)

One way would be to have ParameterizedNode::SingleChildArguments / ParameterizedNode::LastChildrenArguments and ParameterizedNode::WrappedArguments or similar, to denote the 3 different ways Parser encodes arguments?

This could even be handled automatically by ParameterizedNode when there's a def first_argument_index or similar that is encountered, but it feels too much.

[marcandre]

I've refactored this a bit to improve the naming.

Relevant nodes can still include ParameterizedNode, or may include the variants ParameterizedNode::RestArguments or ParameterizedNode::WrappedArguments depending on how their arguments are handled. I added to the documentation which method each rely on (if any).

I'd like to merge this if it sounds ok and cut a release of rubocop-ast...

[bbatsov]

I like the current version.