Implement optional chaining for function call

[andreabergia]

PR stacked on top of #1694

It implements the optional chaining operator for function call, i.e. f?.() and similar.

There is a lot of complexity in this PR caused by the fact that rhino has many different ways of calling a function:

• f() is a NAME_AND_THIS followed by a CALL
• a.b() is a PROP_AND_THIS followed by a CALL
• a[b]() is an ELEM_AND_THIS followed by a CALL
• there are even other cases, such as a.__parent__() or eval.

The approach I've used is similar to the one used for optional property access, i.e. for f?.(x) it will do something like:

lookup f
put this
if isNullOrUndefined {
  pop
  put undefined on the stack
} else {
  evaluate x
  call function
}

This is necessary to do the proper short-circuiting required by the spec (there's a lot of unit test cases to verify them).

There is a little bit of duplication in the code, but I think it makes for much easier reading. Also, the bytecode and runtime code generated for the "normal" function call (non-optional) is exactly the same as before; there are no new branches added.

We pass a lot of test262 cases; the ones we do not are for the following reasons:

• call-expression.js, super-property-optional-call.js: use class
• early-errors-tail-position-null-optchain-template-string.js, early-errors-tail-position-null-optchain-template-string-esi.js, early-errors-tail-position-optchain-template-string.js, early-errors-tail-position-optchain-template-string-esi.js, punctuator-decimal-lookahead.js: these use things like fn``x``?.a which we do not support because we also do not support the non-optional access, i.e. fn``x.a` already does not work. Tracked by Syntax rejected when accessing property of literal objects #1703
• eval-optional-call.js: eval.? has a special semantic that I did not implement. Tracked by Indirect eval call semantics #1704
• optional-chain-prod-arguments.js: there are some existing problems with the spread syntax, tracked by Support ES2015 Spread syntax #1217
• new-target-optional-call.js: uses new.target which is unsupported, but the test is not marked as requiring it. Probably needs a fix in test262.
• member-expression.js: uses async, class, and new.target
• iteration-statement-for-in.js, iteration-statement-for-of-type-error.js: uses for (const key of xxx), which does not work. Tracked by Implement ES2015 const  #939

[rbri]

@andreabergia have started some smoke testing with HtmlUnit....

[rbri]

@andreabergia smoke test was successful

[gbrail]

Thanks -- I merged the previous PR so could you please rebase?

[andreabergia]

Thanks -- I merged the previous PR so could you please rebase?

Done

[gbrail]

This is a lot and it moves us forward a lot! I can see that it fixes a lot of tests, I can see that it fits in our existing structure and it's generally good quality, and it works. I'm happy to merge it and thanks!