Fix input table jpy restriction

[arman-ddl]

Trying to create a custom input table resulted in:

Error in Python interpreter:
Type: <class 'deephaven.dherror.DHError'>
Value: Failed to get input table for 'InputTablesCorePlus.TestViaSpecPython'. : deephaven.dherror.DHError: j_table type is not io.deephaven.engine.table.Table : j_table type is not io.deephaven.engine.table.Table
Traceback (most recent call last):
  File "/usr/illumon/dnd/latest/py/packages/deephaven_enterprise/database.py", line 15, in do_with_dh_error
    result = func()
  File "/usr/illumon/dnd/latest/py/packages/deephaven_enterprise/database.py", line 366, in <lambda>
    return do_with_dh_error(lambda: InputTable(j_table=self.j_wdb.inputTable(namespace, table_name)), F"Failed to get input table for '{namespace}.{table_name}'.")
  File "/usr/illumon/dnd/venv/latest/lib/python3.10/site-packages/deephaven/table_factory.py", line 241, in __init__
    super().__init__(j_table)
  File "/usr/illumon/dnd/venv/latest/lib/python3.10/site-packages/deephaven/table.py", line 434, in __init__
    raise DHError("j_table type is not io.deephaven.engine.table.Table")
deephaven.dherror.DHError: j_table type is not io.deephaven.engine.table.Table : j_table type is not io.deephaven.engine.table.Table
NoneType: None

Somehow missed this line in my testing of Core+ custom input tables until a fresh install. Added a basic test for custom input table creation.

Although BaseArrayBackedInputTable is no longer suitable, should we be more specific than Table jpy requirement, e.g. "QueryTable"?

[jmao-denver]

Modified the Java object wrapping logic to always wrap with the most specific (deepest) descendent class in the class hierarchy

[rcaudy]

Presumably, this is slower than the existing behavior. The only place I can imagine where that might matter is something like a PartitionedTable.transform with a Python function. Does the Java constituent Table get wrapped automatically as a Python Table wrapper, and if so , is it slow enough to matter?

@jmao-denver you might need to test this.

[jmao-denver]

No, they are not. When requested (e.g. via. constituent_tables()), the constituent tables are explicitly wrapped in Table, not through this auto wrapping facility.

[rcaudy]

I don't think that addresses my concern. I am talking about when you pass a Python function (adapted to Java) to transform.
deephaven.table.PartitionedTable.transform

[jmao-denver]

Some quick/minimal testing, ~2 - 4 % slower, the more constituent tables, the slower, which is kinda expected (more wrapping):

def transform_func(t: Table) -> Table:
    return t.update("f = a + b")

t = empty_table(100_000_000).update(["a = i", "b = i + 1", "c = i % 10_000", "d = `text`", "e = i % 1000000"])
pt = t.partition_by(by=["c"])
print("num of constituent tables: ", len(pt.constituent_tables))
print("constituent table size: ", pt.constituent_tables[0].size)
with make_user_exec_ctx():
    st = time.process_time_ns()
    transformed_pt = pt.transform(transform_func)
    print("transform time: ", (time.process_time_ns() - st)/10**9)
    self.assertIsNotNone(transformed_pt)

Before:

num of constituent tables:  10000
constituent table size:  10000
transform time:  42.321798386

num of constituent tables:  1000
constituent table size:  100000
transform time:  20.706249172

After:

num of constituent tables:  10000
constituent table size:  10000
transform time:  44.08636249

num of constituent tables:  1000
constituent table size:  100000
transform time:  21.192759225

[rcaudy]

This addressed two of my concerns