Even higher level bindings

[kkaefer]

Prototyping the introduction of a templated base class for binding to Java objects. This is still missing support for native peers.

The idea is to introduce parallel classes in C++ as well that wrap the jni::Object<...> and expose the Java methods as member functions, implementing the calling syntax proposed in https://github.com/mapbox/jni.hpp/issues/11. The parallel class is freely convertible to/from jni::Object<...>.

It also simplifies creating bindings for those class member functions, removing the need to use macros and verbose syntax. It supports overloaded functions as illustrated in examples/binding.cpp.

/cc @jfirebaugh for feedback on this approach

[haelix888]

I've been working with JNI a lot lately using strategies similar to those in this library. While very good, I ended up writing my own because I didn't understand the purpose of having both low and high-level abstractions, the library (or at least the examples) seemed unnecessarily centered on RegisterMethod, and in the inner workings contain certain things that I could not comprehend (in a short time frame), such as unclear ownership design and some magic regarding "references" in the C++ sense - which the library is trying to assign ownership semantics of some sort.

My biggest source of confusion with high-level wrappers was that the design misses the fact that in this declaration

    template < class TheTag = ObjectTag >
    class Object : public TagTraits<TheTag>::SuperType

TheTag is an abstraction for a Java class. TagTraits is just ancillary information that belongs to the these classes. Therefore StringTag, ClassTag, ArrayTag are classes, not "tags". If the design recognized this, the natural followup is that these classes contain state (the jclass reference) as well as cached jMethodId and jFieldIds. This is how method wrapping could be nicely done IMO.

There are many good takeaways for sure, such as how the constexpr class-names are handled, the wrapping of Arrays with the automatic generation of signatures based on StringLiteral, that part IMO is state of the art and worth using.