INSERT, UPDATE and DELETE against an ADO table fail to plan

[wasabii]

DML does not push down and there is no fallback. Measured, all four of

INSERT INTO ADO.DEPTS VALUES (40, 'New')
INSERT INTO ADO.DEPTS SELECT DEPTNO + 100, DNAME FROM ADO.DEPTS
UPDATE ADO.DEPTS SET DNAME = 'Renamed' WHERE DEPTNO = 30
DELETE FROM ADO.DEPTS WHERE DEPTNO = 30

fail with

There are not enough rules to produce a node with desired properties: convention=ENUMERABLE, sort=[].
Missing conversion is LogicalTableModify[convention: NONE -> ENUMERABLE]

Calcite has three pieces we have none of:

Calcite	ours
JdbcRules.JdbcTableModificationRule	—
JdbcRules.JdbcTableModify (JdbcRules.java:1019)	—
JdbcTable implements ... ModifiableTable	AdoTable : AbstractQueryableTable, TranslatableTable, ScannableTable

The runtime half already exists and is orphaned: AdoUpdateEnumerable executes a non-query and
returns a row count, reachable only from AdoEnumerable.CreateUpdate, which no rule calls. So
execution was written and planning never was.

Two capabilities hang off this that Calcite's adapter does not have, and are worth keeping in view
while it is designed:

• DbBatch for a multi-row modify;
• a bulk-copy path for INSERT ... SELECT whose source is in another convention, which is the
  cross-source shipping machinery pointed at a write.

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".