Make query translation more restrictive

The current query translation approach is rather minimalist, handling some differences between MySQL and SQLite, while leaving other/unknown syntax to fall to default translation handling and relying on the SQL dialect similarities.

For better confidence and data safety, it would be better to implement a more "allowlist"-oriented driver that would be explicit about what syntaxes are supported, leaving the rest as "unsupported". This is needed especially for data-writing queries, less so for read-only queries, in the following order of importance:

1. DDL queries — here it's very important to allow only what we support to keep the information schema consistent.
2. Data-writing queries — it can be important in some cases where an incorrectly understood query would result in a wrong operation.
3. Read-only queries — here, allowlist can be a convenience (bail out early) rather than a necessity.

The full MySQL grammar contains many nodes, variations, and nesting, and it's hard to handle every detail using an allowlist — for instance, a specific construct may be generally valid in an expression, but not in an expression in a subquery in a join, etc. That said, I think we can be very explicit at the higher level — explicitly stating which top-level statements we do support and which ones we don't, and which main subconstructs of these statements are supported or not (e.g., LIMIT clause in a DELETE query).

See: https://github.com/Automattic/sqlite-database-integration/pull/1#discussion_r1951062367

Start by reviewing the current query translation approach and the linked pull request discussion. Define which top-level DDL, data-writing, and read-only statements and main subconstructs are supported, then verify that unsupported syntax is rejected rather than passed to default translation.