This adds some significant JNI glue in order to make the Java API for
gltfio materials much more consistent with C++, and create feature
parity between the two languages.
The motivation is to allow Java clients to provide their own
ubershader-based solution or filamat-based solution.
- The `MaterialProvider` Java class is now an interface.
- The `UbershaderLoader` Java class is now a concrete implementation.
- Users can now write their own provider class using Java / Kotlin.
To streamline the amount of JNI work that occurs at run time, the
MaterialProvider Java interface uses ints in a couple spots instead
of enums. This sacrafices some readability for Java clients who wish
to write their own provider, but makes the JNI much simpler.
This replaces #3975.
We currently use static linking and will continue to do so. This means
that libfilament-jni is a subset of of libgltfio-jni, and libgltfio-jni
will become a subset of the upcoming libutils-jni.
This is a simple layer cake, but requires adding some CMake logic to the
gltfio-android CMakeLists, similar to what we already did for the
filament-android CMakeLists. This prevents an obscure CMake error about
duplicated build artifacts.
Also, previously we required clients to call AssetLoader#init(), this
is now renamed to Gltfio#init(), which is more consistent with
Filament#init().
For now this uses gltfio in the ubershader configuration in order
to avoid the filamat dependency. Note that we have not yet done a size
analysis of the `gltfio_core` library.
New Kotlin-based sample app is forthcoming.
