Separate varargs and specific-arity names in JIT. Fixes #4482

[headius]

Originally, varargs and specific-arity paths were emitted in toto
as their own JVM method bodies. With recent changes, the varargs
path now calls the specific-arity path, causing an extra
synthetic entry in the JVM stack trace. This confounded the
backtrace miner, since it had no marker with which to omit the
synthetic version, and so Kernel#caller and friends contained an
additional invalid entry. This in turn caused require_relative to
fail to find the caller's path, resulting in a nil path value
passed to File.realpath, which triggered this bug.

It likely only affected invokedynamic because our indy logic must
be calling no-arg methods via the varargs path (a separate issue
to be fixed).

My modification here explicitly separates the synthetic varargs
name from the specific-arity name by adding a known varargs marker
that can be filtered out when mining the backtrace.

This is a big hacky; the state being managed by the jit is very
ad-hoc and prone to bugs. It will need some additional cleanup
after 9.1.8.0.

See #4482.

[headius]

The additional "issue" I mentioned is a non-issue for now. Indy will always call through the varargs path the first time a call site is bound, since it only has a single varargs binding path in InvokeSite. Fixing the issue would require having separate bootstrap logic for each arity, and would only save us the varargs array and overhead on the first (re)bind of a given call site.

Since most indy sites will eventually settle into one or more direct variable OR specific paths, this is not necessary. However, we may want to fix it for sites that fail to bind, such as those that have too many targets or that are rebound too many times.