Clarify and/or fix methodCall argument

[devinrsmith]

The methodCall boolean argument does not cause any functional difference in org.jpy.PyLib#callAndReturnObject nor org.jpy.PyLib#callAndReturnValue. https://github.com/jpy-consortium/jpy/blob/v0.11.0/src/main/c/jni/org_jpy_PyLib.c#L2364-L2378

I'm not sure if this was a historical cpython requirement, or if there is some other missing context. It is possible that the argument should be removed from the hierarchy to reflect the actual implementation.

[niloc132]

I think I might suggest going a bit further here, since it doesn't really make sense to have a Callable as a property as the default case - usually, you just have a Callable instance directly. The deephaven-core codebase has several cases where we explicitly invoke __call__ on a callable, so that the Callback need not be wrapped.

        PyObject out = pyCallable.call("__call__", wrapped, wrappedOther);

It makes sense to use the name parameter if the non-method function has been assigned as a property to an object, but that probably isn't the default case. As such, where possible, I would suggest removing the name parameter (probably deprecated the call() methods that had a name, and encourage moving to a format where only parameters are passed in.

Due to varargs confusion, it might make sense to use a new method name with these semantics - perhaps invoke?

Finally, this could be a good time to switch out the overloads that always return PyObject and require the caller to specify the return type for primitives (and string), and possibly revisit the proxy handler implementation for the same. It could make sense for specific concrete types to encourage more use of proxies, make them easier to automatically be the right answer.