Resolve compiler issues for common compiler configurations

[jwhpryor]

Some common compilers (such as those bundled with the Android NDK on stock Bazel) have outdated or non-conformant clang implementations.

Some of these legal but unsupported syntaxes could be obviated with equivalent but supported implementations.

[jwhpryor]

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.

[jwhpryor]

After some extensive digging, I'm now convinced the existing syntax will be impossible to support in other compiler implementations.

I'm going to add two new functions when C++20 (or higher) is present with syntax like so:

LocalObject<kObj> obj {};
obj.Call<"yourJavaFunctionName">( ... ) ;
obj.Access<"yourJavaFunctionName">( ... ) ;

I will leave the existing syntax available when clang is present, since these functions can peacefully co-exist (and will even be able to share the other's cacheing).

I'm disappointed maintaining the existing syntax isn't possible going but I think this strikes the best balance for compatibility.