Consider either re-exporting ndk crate or encapsulating the ndk crate API

[rib]

Similar to how the Winit crate re-exports the android-activity API it could make sense for this crate to re-export the ndk crate's API so that downstream crates don't need to have an explicit ndk dependency in their Cargo.toml whose version needs to be synchronized with android-activity in case they want to use types (like AssetManager and NativeWindow that are exposed in the public API for android-activity)

(In the case the we re-export the ndk crate that would only really be convenient if the Winit crate were to also do the same, and forward the ndk API from android-activity)

Alternatively the ndk API could be fully encapsulated as an internal implementation detail by defining our own new types for the Asset Manager and Native Window.

Ref: bevyengine/bevy#6830 + bevyengine/bevy#6830 (comment)