[rib]

This adds support for an optional android_on_crate entrypoint which is called from within the Activity.onCreate native method callback from the Java main / UI thread.

For example:

use std::sync::OnceLock;
use jni::{JavaVM, objects::JObject};

// Called while Activity.onCreate is running
// May be called multiple times if the activity is destroyed and recreated.
#[unsafe(no_mangle)]
fn android_on_create(state: &android_activity::OnCreateState) {
    static APP_ONCE: OnceLock<()> = OnceLock::new();
    APP_ONCE.get_or_init(|| {
        // Initialize logging...
        //
        // `android_on_create` may be called multiple times but some
        // logger crates will panic if initialized multiple times.
    });
    let vm = unsafe { JavaVM::from_raw(state.vm_as_ptr().cast()) };
    let activity = state.activity_as_ptr() as jni::sys::jobject;
    // Do some other setup work on the Java main thread before `android_main` starts running
}

This gives applications an opportunity initialize state while the Activity's class loader is on the stack, so FindClass will be able to find application classes.

This can be a more-convenient place to initialize JNI bindings, without needing to explicitly get the class loader from the Activity to be able to look up application classes from the android_main thread.

This may also be convenient for initially using JNI to interact with your new Activity in case you need to use SDK APIs that are only safe to use from the Java main / UI thread.

This moves the thread initialization functions out of util.rs into a new init.rs

While adding documentation for this feature, this also does a more-general pass over the top-level crate documentation to try and ensure it's up-to-date.

Fixes: #169
Addresses: #82