Issue Description:

We can't do much with swift on android without a working JNI bridge.

I've got a "MVP" solution working here:
https://github.com/SwiftAndroid/swift-jni

It provides a thin wrapper over the C API, with some more OOP structure (currently via a 'jni' global, which is not very Cocoa-like), with some nil checks and optionals to make it more swift-like. There's also a wrapper to make JavaCallbacks using a jniGlobalRef of your Java instance and possibly a couple of other experiments that I've forgotten about.

The question is, should this be a part of swift core or continue to be maintained by the community? To me the answer to this should be based on whether we see an Android port as useful without it.

Maybe we can have a CJNI package that does little more than wrap the headers, and a community package that makes it more swift-like? On the other hand, this is Swift. Why not have a half-decent Swift API built in?

I'm looking for guidance as to how to continue this conversation and how to proceed with the JNI module I linked to above.