[ItsDeadlyProgrammer]

The INSERT OR <algorithm> form was parsed by the separate Upsert() production, so it rejected
the clauses the plain INSERT production supports:

INSERT INTO t (a) VALUES (1) RETURNING a                        -- parses
INSERT OR IGNORE INTO t (a) VALUES (1) RETURNING a              -- failed
INSERT OR IGNORE INTO t (a) VALUES (1) ON CONFLICT DO NOTHING   -- failed
INSERT OR IGNORE INTO t DEFAULT VALUES                          -- failed

Change

• SingleStatement() reads INSERT OR <algorithm> with Insert(), behind Dialect.SQLITE.
• Insert() accepts [ <K_OR> algorithm=RelObjectName() ] after <K_INSERT> and stores it as
  InsertConflictAlgorithm (OR_ABORT, OR_FAIL, OR_IGNORE, OR_REPLACE, OR_ROLLBACK),
  rendered by appendInsertPrefix(); Insert.omitInto keeps SQLite's optional INTO.
• Upsert / UpsertDeParser are untouched: REPLACE without OR and PostgreSQL's UPSERT parse
  exactly as before. Folding REPLACE in touches callers that cast to Upsert (ReplaceTest,
  MySqlInsertSourceTest, ReplaceValidatorTest) and is left for a second PR.

Tests

SQLiteTest gains testInsertOrConflictAlgorithmIsAnInsert,
testInsertOrKeepsTheInsertClauses (ON CONFLICT, RETURNING, DEFAULT VALUES, alias) and
testInsertOrKeepsTheOptionalInto.

Full suite: 13112 tests, no new failures compared to master; SQLiteTest 41/41 green. A sweep of
all 322 .sql fixtures in src/test/resources produces identical parse results and deparsed output
on the patched and unpatched parser.
Part of #2852.

[manticore-projects]

Thank you!