hawtjni standard-template files broken on arm64 (though has warnings on others) in latest Android NDK (10)

[harningt]

Somehow the callback tables are being considered as having values not known at compile time on arm64.
Only pasting a few because the pattern is the same and results in a ton of error output...

.../jni/hawtjni-callback.c:352:3: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
   (jintLong)FN(0, args), \
   ^
.../jni/hawtjni-callback.c:486:3: note: in expansion of macro 'FN_A_BLOCK'
   FN_A_BLOCK(0)    
   ^
.../jni/hawtjni-callback.c:486:3: error: initializer element is not constant
.../jni/hawtjni-callback.c:486:3: error: (near initialization for 'fnx_array[0][0]')
.../jni/hawtjni-callback.c:353:3: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
   (jintLong)FN(1, args), \

If I inject (long) in between "(jintLong)" and "FN" in FN_A_BLOCK(args) I get rid of the cast from pointer to integer of different size... but that is a somewhat disturbing result.
With that I still get the 'initializer element is not constant' error...

I'm not quite sure what is going on with that platform... I suspect jintLong is 32-bits which is causing the pointer-to-int-cast issue when attempting to store function pointers in 32-bit form... very frightening because I think that the most common use of jintLong is to store pointers that need to get passed 'safely' into Java land.

A fix that removes the errors is to modify the FN_A_BLOCK segment to remove the (jintLong) cast of the function pointer and to change the actual array itself to be 'void*' instead of jintLong typed (really, function pointers should be stored as raw pointers, I would think... and at barrier points (and as I see, in the jni-call function I see return (jintLong) fnx_array[argCount][i] ... which raises warnings at build time.

The (void **) casts of the env variable is causing issues in hawtjni.c and hawtjni-callback.c because the compiler is being more type-strict.

.../jni/hawtjni.c: In function 'hawtjni_attach_thread':
.../jni/hawtjni.c:54:12: warning: passing argument 2 of '(*JVM)->AttachCurrentThread' from incompatible pointer type
     return (*JVM)->AttachCurrentThread(JVM, (void**)env, &args);
            ^
.../jni/hawtjni.c:54:12: note: expected 'const struct JNINativeInterface ***' but argument is of type 'void **'
.../jni/hawtjni-callback.c: In function 'callback':
.../jni/hawtjni-callback.c:710:7: warning: passing argument 2 of '(*jvm)->AttachCurrentThreadAsDaemon' from incompatible pointer type
       (*jvm)->AttachCurrentThreadAsDaemon(jvm, (void **)&env, NULL);
       ^
.../jni/hawtjni-callback.c:710:7: note: expected 'const struct JNINativeInterface ***' but argument is of type 'void **'
.../jni/hawtjni-callback.c:716:5: warning: passing argument 2 of '(*jvm)->AttachCurrentThread' from incompatible pointer type
     (*jvm)->AttachCurrentThread(jvm, (void **)&env, NULL);
     ^
.../jni/hawtjni-callback.c:716:5: note: expected 'const struct JNINativeInterface ***' but argument is of type 'void **'

Fix for those - drop the void** cast.

Sorry for the long-winded ticket, attempting to get lmdbjni building fully for Android w/ all platforms to test out some optimized handling and running into trouble.

[puntogil]

Also on Fedora Linux (aarch64, ppc64, ppc64le arches)

[felixvf]

Note that #20 fixes this bug.
@chirino Is there any reason to not merge PR #20?