Remove workaround when ConvertService can operate on python types

[hinerm]

This commit adds a workaround to a JPype limitation. Without it, when trying to convert python types (even if a valid converter implementation exists) we get this error:

TypeError: No matching overloads found for org.scijava.convert.ConvertService.supports(tuple,_jpype._JClass), options are:
        public default boolean org.scijava.convert.ConvertService.supports(java.lang.Class,java.lang.Class)
        public default boolean org.scijava.convert.ConvertService.supports(java.lang.Object,java.lang.Class)
        public default boolean org.scijava.plugin.HandlerService.supports(java.lang.Object)
        public default boolean org.scijava.convert.ConvertService.supports(java.lang.Class,java.lang.reflect.Type)
        public default boolean org.scijava.convert.ConvertService.supports(java.lang.Object,java.lang.reflect.Type)

When this is fixed in Jpype we can remove the workaround

[ctrueden]

There are valid Converter plugin implementations for python types like tuple? Where? And what Java type does a tuple present as on the Java side? This magic feels dangerous to me in general... I feel like the commit making the line lambda obj: isjava(obj) and ij().convert().supports(obj, jc.DatasetView) is actually correct... or else it should be conceptually lambda obj: ij().convert().supports(ij.py.to_java(obj), jc.DatasetView) although that way would end up doing lots of pointless Python-to-Java conversions in the background.

[Thrameos]

JPype likely won't ever support conversion of a tuple because it has no Java type unless there is some generic container type what it could be mapped to. Can I ask what code triggered this particular error? (what is in the tuple and what should it convert to?)

[gselzer]

@ctrueden @hinerm the commit making that line isn't wrong per se, it just stinks that python objects can reach that code. scyjava.to_python doesn't ensure that the argument is a java object, so calling scyjava.to_python(my_java_object) results in us having to defensively program within the predicates.

It's worth noting that this happens because in pyimagej there's a redundant conversion in java_to_xarray (which I fixed in imagej/pyimagej#257), that just must have not released yet. But that doesn't fix things in the general case; we'd need a fix to scyjava for that.

@Thrameos it's definitely not an issue with JPype, and I think your reasoning about not supporting tuple conversion is correct. The tuple contains napari Layer (i.e. Python) objects, and it should not convert to anything because the method we're trying to call is meant to convert java objects into another type of java object.

[gselzer]

Note that scijava/scyjava#60 should enable us, when we can depende on it, to remove these checks