These paths are automatically arity-checked but only along the
DynamicMethod.call path. This leaves direct Java calls and indy
binding without arity checking. Given the impossibility of
automatically arity-checking the direct call paths, it seems best
to always arity-check inside variable-arity native methods. We may
want to audit all such places and remove the automatic arity-
checking happening in DynamicMethod.call(..., IRbuyObject[]) so
we are always checking at the point of use, where the stack trace
will reflect the method name, and without double-checking in both
generated wrappers and in the method itself.

In order to ensure that arity checks always happen along variable-
arity paths, it makes sense for us to move the check into the
method bodies rather than relying on the generated wrapper or the
caller to do the check. This has several advantages:

* Direct calls from Java will now be checked.
* Direct calls from invokedynamic call sites will be checked.
* The generated invokers will have less data and do less arity-
  checking.

Splitting methods by arity will still enable direct calls to
bypass the arity check.

The pattern I used here, which we may want to adopt as a
recommended pattern, is as follows:

* If the method accesses the contents of the array direct or
* If the method passes the array on to other code that accesses
  its contents directly without a check then
* A manual arity-check should be performed before any other
  operations.

This will be fixed once ruby/stringio#48 is merged and released.