The catalog shows tables only: no functions, no procedures, no types #117

AdoSchema.cs:76 builds every discovered object as Schema.TableType.TABLE, so a view is
indistinguishable from a table and system tables are not marked. Calcite maps the driver's reported
type through Util.enumVal, giving VIEW, SYSTEM_TABLE and OTHER (JdbcSchema.java:310-324).
The fix is in the AdoDatabaseMetadata implementations that enumerate tables.

Beyond that, AdoBaseSchema.getFunctions and getTypeNames return the empty defaults, so a
server-side table-valued function or stored procedure cannot be named in a query at all.
RelToSqlConverter.visit(TableFunctionScan) writes TABLE(f(...)), and ADO.NET reads a procedure's
shape through CommandType.StoredProcedure and DbDataReader.GetSchemaTable.

The same reader-shape route would give a raw-SQL passthrough table macro, which is the escape hatch
an adapter of this kind eventually wants.

How this was measured

A scratch test class in Apache.Calcite.Adapter.AdoNet.Tests ran thirty statements against the
SQLite fixture, each twice: once as EXPLAIN PLAN FOR to read the physical plan, once for real
with a Hook.QUERY_PLAN handler counting the statements the adapter sent. Recorded in TODO.md
under "ADO.NET adapter: what more it could push".