Better support for `Error` type in JNI mode.

A common Swift pattern for throwing functions:

enum MyError: Error {
  case firstError
  case secondError
}

func throwingFunc() throws {
  throw MyError.firstError
}

Today in the JNI mode, we can extract throwingFunc and MyError correctly.
However, there is currently no good pattern to know what kind of error was thrown. The best we can do is check the exception message thrown from Java.

It would be nice if we could a type-safe "is this MyError.firstError?"

Accessing the underlying error.

The FFM mode currently has its own SwiftJavaErrorException, which just contains the error description.
In JNI, we just throw a generic Exception with the Error string representation.

With #814 and #819 we can now return protocol types and cast them to their concrete types. If we could do something similiar to FFM mode and wrap a SwiftJavaErrorException that looks like:

public final class SwiftJavaErrorException extends Exception implements JNISwiftInstance {
  public Error getUnderlyingError() {
     // Returns the underlying error from the Swift wrapper.
 }
}

then we could do something like:

try {
  MySwiftLibrary.throwingFunc();
} catch (SwiftJavaErrorException ex) {
  Optional<MyError> myError = ex.getUnderlyingError().as(MyError.class)
  if (myError.isPresent()) {
    // now we can access cases of MyError.
  }
}

Alternative

An alternative solution we could look into is somehow getting MyError to conform to Exception?

Start by comparing the FFM mode's SwiftJavaErrorException with JNI's current generic Exception behavior, then review the protocol-type support described in #814 and #819. Determine whether JNI should expose an underlying Error or use the Exception-conformance alternative; done means callers can identify and access concrete Swift error types without parsing messages.