[Java.Interop-Tests] Fix JniTypeTest.Name() missing argument

[jonpryor]

Context: dotnet/android#3393

When running the JniTypeTest.Name() unit test within Xamarin.Android,
sometimes the unit test runner process would crash. The crash is
more likely in Release runtimes:

F o.Android_Test: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: use of invalid jobject 0xc58fa798
F o.Android_Test: java_vm_ext.cc:570]     from void crc64f295cabbf85394f5.TestSuiteInstrumentation.n_onStart()
F o.Android_Test: runtime.cc:630] Runtime aborting...

What was particularly odd about this crash was that after enabling
both GREF and LREF logging, there was no handle 0xc58fa798!

Where was this invalid handle coming from?

Turns Out™, 0xc58fa798 isn't a handle. Instead, it's a parameter
mismatch!

Commit 9f380eb had a bug. JniTypeTest.Name() was attempting to do:

// Java
java.lang.reflect.Method Object_hashCode  = Object.class.getMethod("hashCode", new Class[0]);
String Object_hashCode_returnType         = Object_hashCode.getReturnType();

However, via JNI, it was actually doing:

java.lang.reflect.Method Object_hashCode  = Object.class.getMethod("hashCode", GARBAGE_VALUE);
String Object_hashCode_returnType         = Object_hashCode.getReturnType();

because it was only passing one value to Class.getMethod(), not
two values, so the second parameter was entirely undefined and
unknowable.

Through sheer luck (or a terrible bug) this "worked" on a Desktop JVM
and (frequently) in Debug configuration builds of the
Mono.Android_Tests-*.apk test app in Xamarin.Android.

On Android in a Release configuration, GARBAGE_VALUE was treated as a
garbage value, and brought down the process because there was, in
fact, a JNI error in the application.

Fix JniTypeTest.Name(), and pass the correct number of parameters to
Class.getMethod(String, Class[]).

Additionally, make two (mostly unrelated) changes:

• Add a JniType.ToString() override.
• Change the exception ordering in `JavaExceptionTests.StackTrace().

While debugging the above crash, I attempted to use
JniType.ToString() in some debug messages. These were useless,
because there was no JniType.ToString() override.

Add one.

The conceptual problem JavaExceptionTests.StackTrace(), meanwhile,
is that eventually Java.Lang.Throwable will be updated to inherit
from Java.Interop.JavaException. If JavaException is caught
first, then the __ANDROID__-specific behavior around
Java.Lang.Throwable will no longer be tested, and the test will
continue to pass (while testing subtly different behavior). Reorder
the catch blocks so that when the Java.Lang.Throwable base class
changes, the semantics of the test will be unaltered.