Bug: Opal follows Ruby <=2.6 rules regarding **kwargs

[hmdne]

Describe the bug
As of now, Opal follows Ruby <=2.6 rules regarding how **kwargs are handled. See:

• https://rubyreferences.github.io/rubychanges/2.7.html#keyword-argument-related-changes
• https://rubyreferences.github.io/rubychanges/3.0.html#keyword-arguments-are-now-fully-separated-from-positional-arguments
• https://www.ruby-lang.org/en/news/2019/12/12/separation-of-positional-and-keyword-arguments-in-ruby-3-0/

We have got only a preliminary **nil support, see: #2240

We support delegation 3.0 level, see: #2153

Note: I think that breaking with our unspoken policy of upgrading to new Ruby versions behavior not being considered a breaking change, this SHOULD be considered a breaking change and be targeted at a major version release. This change is the main reason of incompatibilies between Ruby 2.7 and 3.0 and I would say at least 50% of the code running using Opal is Opal specific (ie. not executed with Ruby). At best, we should try to match the Ruby 2.7 behavior in the 1.x lineup and warn when the last argument is a hash.

Opal version: master

[hmdne]

Idea: If we are to refactor this, shouldn't kwargs be treated similarly to how block is currently handled? I'm not a big fan of defining $$p as a property of a function though.

[elia]

@hmdne I agree 100% on the release plan toward the updated behavior.
About how to implement them, I thought for a long time that Ruby could benefit from a Symbol only keys version of Hashes which should be used for kwargs as well. This would lend itself to better performance and looks like MRI is internally doing something among those lines. For us that would also mean we could use pure JS objects to represent it and have the full-fledged Hash to be a subclass of it.

Thoughts on this direction?

[eregon]

FYI **kwargs can contain non-Symbols on Ruby 2.7+

[janbiedermann]

See #2568