GitLab

This is necessary (but not sufficient) for debugging third-party JNI bugs.
It's the second half of the logging story, but still doesn't address the
question of "how does the developer turn on the logging?".

This removes the variant JNI bridges at the cost of adding a couple of
booleans to struct Method. Performance is about the same, except synchronized
native methods are quite a bit faster after the change.

Before:
                             benchmark  ns linear runtime
                      _emptyJniMethod0 333 ==========
                      _emptyJniMethod6 367 ===========
                     _emptyJniMethod6L 921 ==============================
                _emptyJniStaticMethod0 259 ========
                _emptyJniStaticMethod6 287 =========
               _emptyJniStaticMethod6L 873 ============================
    _emptyJniStaticSynchronizedMethod0 404 =============
          _emptyJniSynchronizedMethod0 452 ==============

After:
                             benchmark  ns linear runtime
                      _emptyJniMethod0 344 ==========
                      _emptyJniMethod6 348 ==========
                     _emptyJniMethod6L 969 ==============================
                _emptyJniStaticMethod0 265 ========
                _emptyJniStaticMethod6 293 =========
               _emptyJniStaticMethod6L 968 =============================
    _emptyJniStaticSynchronizedMethod0 265 ========
          _emptyJniSynchronizedMethod0 323 ==========

A better optimization for the case where there are reference arguments
would be to keep a list of argument indexes in the struct Method, so we
could iterate directly over those arguments that need converting to
local references. That would also let us do something about the overhead
of repeatedly looking up which local reference table and cookie to use.

But now is not the time.

Change-Id: Ie32daca1b31be057a44f1ed4b5d28d1634380e1d