Weird/UB `ndk` APIs found by removing NIHisms in `android-activity`

android-activity open-codes a lot of ndk-provided API, directly on top of native functions and symbols from ndk-sys. While attempting to remove most of it to simplify and clear up the implementation with safer Rust, I found that the ndk could do some things quite a bit better, even if only by documenting expectations. Perhaps this is why certain things were open-coded in the first place, besides being ported from raw C code.

Since the ndk crate is quite old by now, and has seen a lot of "Just Make it Work™", things like lifetime management and correctness when it comes to safety/UB have not always been kept in mind while writing bindings. Instead of creating a lot of separate issues (or PRs) right now, I am using this issue as a public scratch-pad to keep track of questions and ideas that need to tracked and looked into later.

• NativeActivity returns &Paths from raw pointers: could these ever be null()/None?
• NativeActivity::asset_manager() has no lifetime: this should be bound to &self or is it "Application-global"?
• InputQueue has no lifetime and no Drop/Clone: document its lifetime guarantees and return borrows where necessary?
  Its lifetime is tied to the onInputQueueDestroyed callback whose docs describe that:

  You should no longer try to reference this object upon returning from this function.

• ForeignLooper (and various other structures, see https://github.com/rust-mobile/ndk/issues/309) cannot be created without lifetime management, i.e. to temporarily borrow/handle the pointer safely while it is valid inside a callback.
  For lack of unsafe fn borrow_from_ptr(NonNull...) -> &'unknown Self (impossible to write in Rust anyway), it seems most convenient to call let looper = ManuallyDrop::new(ForeignLooper::from_ptr(looper)); now.

Start by reviewing the NativeActivity, InputQueue, and ForeignLooper APIs described in the issue, then read the linked issue #309 and the Android onInputQueueDestroyed callback documentation. This is a scratch-pad of questions rather than a scoped change; done would require turning an agreed API or safety concern into a separate, actionable issue or PR.