Reenable respond_to? caching logic.

The respond_to? call site logic was disabled because it did not
take into account respond_to_missing?. Whenever respond_to?
returns false, 1.9+ needs to check respond_to_missing? in case the
method in question is implemented by method_missing. We disabled
all respond_to? caching until we could figure out a safe way to do
this caching in 1.9 mode.

In this commit, we use the following logic to know whether we can
cache the result of a respond_to? call:

IF we are in 1.8 mode
OR respond_to? returned true
OR respond_to_missing? is not overridden
THEN cache

We will not cache, then, if we're running in 1.9 mode AND
respond_to? returned false AND there's a custom
respond_to_missing? defined. This should cover all appropriate
failure cases and allow us to cache the much more common normal
respond_to? cases.

Numbers before and after:

BEFORE:
                                          user     system      total        real
control, 1 and :to_ary                0.030000   0.000000   0.030000 (  0.031000)
1m 1.respond_to?(:to_ary)             0.060000   0.000000   0.060000 (  0.061000)
1m 1.respond_to?(:to_ary,true)        0.070000   0.000000   0.070000 (  0.069000)
1m 1.respond_to?(:next)               0.040000   0.000000   0.040000 (  0.034000)
1m redefined obj.respond_to?          0.020000   0.000000   0.020000 (  0.025000)
1m varying name respond_to?           0.030000   0.000000   0.030000 (  0.026000)

AFTER:
                                          user     system      total        real
control, 1 and :to_ary                0.030000   0.000000   0.030000 (  0.032000)
1m 1.respond_to?(:to_ary)             0.010000   0.000000   0.010000 (  0.011000)
1m 1.respond_to?(:to_ary,true)        0.010000   0.000000   0.010000 (  0.015000)
1m 1.respond_to?(:next)               0.010000   0.000000   0.010000 (  0.011000)
1m redefined obj.respond_to?          0.020000   0.000000   0.020000 (  0.023000)
1m varying name respond_to?           0.020000   0.000000   0.020000 (  0.024000)

In additionm this should reduce calls to our per-class cache
substantially in cases where the argument passed to respond_to? is
the same and the target object's type is not changing.
Temporary fix for cost of Hash#[] dynamically calling #default.

This fix adds "default" to the list of methods we build up a
per-runtime set of call sites for. I consider this a temporary
fix because that set of sites is a matrix of class count * method
count, so adding default adds another entire row/column when it
will only be used from one class.

It's clear we need some better logic for doing call site caching
for dynamic calls in Java code, but this will work for the moment.
Reduced the number of String allocations for the NONE parameterList case.
Merge pull request #1399 from nirvdrum/reduce_string_duplication

Reduced the number of String allocations for the NONE parameterList case.
Fix shebangs in binstubs AGAIN.
Duplicate kwargs hash before assignment logic. Fixes ##1403.

Note that this implementation is much more costly than it should
be since it mutates the hash while it assigns variables. The new
duping makes it even more costly, but avoids the damage it caused
to the incoming hash.
Clear frame name when duplicating it for a class body. Fixes #1402
Remove unnecessary synchronization from initObjectId. Fixes #1400.

The synchronization here is not actually necessary since the
variable accessor has already been allocated and the object's
monitor has already been acquired (both in getObjectId, the sole
caller of initObjectId). This synchronization caused global
bottlenecks against a given class, since it synchronized against
the VariableTableManager instance from that class. Since it's
likely that if user code acquires an object_id from one instance
of a class, it will acquire object_id from all instances of the
class...this quickly ran into multithreaded contention.

I opted to remove the synchronization, because I believe it is
safe, and modified initObjectId's visibility to be private so it
won't mistakenly be called by external code.
Move SecureRandom.random_bytes to native, to avoid JI costs.
Use a per-thread SecureRandom and move #hex into native.
the script which created the bat only worked if bin/jirb.bat was there and writable - which might have been the error for #1409

[skip ci]
Don't use iterator for walking nodes to avoid allocating one.
AVoid allocating NextJump when result is just nil.

This is by far the most common use of NextJump.
Generate JITted code sexp digest directly rather than from string.
Make Node implement List<Node> to avoid making one-element lists.
Eliminate some Java 5 iteration of AST node lists.

Java 5 iteration along hot or boot paths causes a lot of transient
iterator objects to be created. This patch removes some such cases
that appear to be along hot paths or paths hit heavily at boot.
Efficient arity-specific paths for constructing List<Node>.
For very large case/when, spill when bodies into JVM methods.

Many Ruby libraries use very large case/when statements. For
example, generated parsers, such as the one in whitequark/parser.
These large cases often do not JIT on JRuby because their JITed
size exceeds the bytecode size limits of the JVM. Some may compile
but then optimize poorly because the JVM decides it is a "huge"
method that's not worth optimizing.

This patch adds a configurable knob compile.outline.casecount that
specifies a count of cases (when bodies) in a case above which the
bodies will be emitted into their own JVM methods and
single-method optimizations are disabled. Currently this threshold
is set to 50 cases, but this is a somewhat arbitrary estimate
based on the roughly 30-50 bytes of bytecode required just for
the when matcher logic. 50 * 50 = 2500 bytes just for matching,
and then the when bodies are usually much more code.
Fix bad tracing test exposed by recent in-class method name fix.
Revert "Make Node implement List<Node> to avoid making one-element lists."

This reverts commit 0ae2a78b0598c8a31fa12cf8d51a6edf2d902bc5.

Several nodes implement ListNode add(Node) which conflicts with
boolean add(T) from java.util.List.