Resolve compiler issues for common compiler configurations about jni-bind HOT 1 OPEN

Some of this may be impossible without either changing the call syntax or waiting until the library can support C++20.

There are a couple alternatives:

1. Provide a slower solution for non-clang alternatives. This could likely be reduced to a single dereference per method invocation (the correct idx can still be inferred compile time).
2. A syntax that explicitly requires providing the idx as a template argument based on a constexpr method invoked from the constexpr class. E.g.

LocalObject<kClass> obj {}.Call<kClass.idx("Foo">(...);

This introduces a lot of duplication and isn't visually appealing.

3. Wait until C++ 20string literals are available and cut a library release that isn't backwards compatible.

Relevant links:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0424r2.pdf
http://je4d.s3.amazonaws.com/D0732R0-wip.pdf
https://artificial-mind.net/blog/2020/11/14/cpp17-consteval

Even still, this option may require a new syntax because operators can't be cleanly templated. E.g. you may need to write the syntax:

obj.template<"Foo">( ... );

Here at least we could offer a new syntax:

obj.Call<"Foo">( ... );

This would maintain dual compatibility but would be sad to introduce a new call syntax. It's unclear to me if consteval could provide a consistent syntax to what exists today.

4. Look for a gcc equivalent of the function argument enable_if. This isn't particularly good long term either though.

What's unfortunate is that the correct idx can be inferred at compile time at the call site, but not once the member method has been invoked. C++17 has everything it needs.

I don't think this is trivial to resolve, so, I will leave this as an open problem, but not blocking for release. I tried every trick I had.

from jni-bind.