Extend the EET DML oracle to INSERT support - #1358

The EET DML oracle (EETDMLOracle) previously transformed DELETE and UPDATE statements. This PR adds INSERT to the same oracle.

The INSERT is generated in the INSERT ... SELECT form rather than INSERT ... VALUES. This is because, when a value expression is transformed, the transformer introduces equivalent sub-expressions that reference the table's columns (for example, the random predicate inside a CASE WHEN). Column references are legal in a SELECT but not in a VALUES clause, so a VALUES form would produce invalid SQL without additional workarounds. Note, this does NOT mean that the testing is limited to only insert column references. It can still insert new constants too. For example, INSERT INTO t (c1) SELECT (123) FROM t WHERE p would insert n rows with the constant 123, where n is the number of rows in t which satisfy p. So, the INSERT ... SELECT form is expected to stress the DBMS at least as much as the INSERT ... VALUES form would.

Because INSERT ... SELECT inserts one new row per source row, each new row needs an identifier so the two runs' states can be lined up. Although the existing rows are originally stamped with UUID(), this cannot be used for the inserted rows, because it would be non-deterministic across the two runs. The implementation chosen here for MySQL simply removes the four dashes from the existing row's rowid, using REPLACE(rowid, '-', ''). This is deterministic (both runs assign the same identifiers), unique per source row, and distinct from every existing identifier (a 32-character string never equals the 36-character source string). It also fits the existing identifier column without widening it.