The ruby2_keywords method is used to switch a method or block to
use Ruby 2.x keyword argument behavior, based on a normal Hash
passed as the last argument. When this behavior changed for Ruby
3.0, ruby2_keywords was provided as a way to indicate the old
behavior is required for a given scope.

Recent optimizations to kwarg handling in JRuby assume that by the
time JIT has happened, the ruby2_keywords bit has already been set
or will never be set, so we can avoid checking it on each call.
This works fine for normal situations, but under the following
circumstance (found only in CRuby tests, so far), JIT may happen
before the call to ruby2_keywords, and the compiled code uses the
wrong (Ruby 3) logic:

* Scope 1 (a method or block) contains the definition of scope 2
  (another method or block).
* Scope 1 also calls ruby2_keywords to alter the kwarg behavior of
  scope 2.
* Scope 1 gets compiled immediately (no interpretation), which
  forces scope 2 to compile immediately *before* ruby2_keywords
  can be called.
* As a result scope 2 is pinned to Ruby 3 kwarg behavior and
  because immediately-compiled child scopes do not have a way to
  deopt back to interpreter, the ruby2_keywords behavior is never
  reflected.

This situation is extremely rare; only a few unusual cases can
trigger it:

* Whole-script AOT compilation, because the methods get compiled
  before executing code that calls ruby2_keywords.
* JIT with threshold=0 and method or block bodies that contain
  child scopes intended to use ruby2_keywords, as described above
  and found in CRuby tests.
* Code that defines methods, allows them to be called enough times
  for JIT, and some time after JIT attempts to set ruby2_keywords.

Because of the unusual circumstances that can cause problems, this
patch disables compilation for any scope that contains calls to
ruby2_keywords, which solves the first two scenarios. The third
scenario is not fixed by this, but is by far the most rare and
least concern of the three; if the method is being called before
ruby2_keywords is calls, then by definition it needs to work
properly with Ruby 3 kwarg logic, so the failure to switch to Ruby
2 kwarg logic should not be apparent.

A future update to JRuby may improve our ability to "back off"
from jitted code and recompile if ruby2_keywords is called.