Add MariaDB backend

[phdoerfler]

This adds MariaDB as a backend. Again, I let the LLM do the most of the work similar to the other recent backend additions (SQLite #864, H2 #866, MySQL #872): The LLM was instructed to do TDD and perform a critical review and I looked over the mapping code as well. Depends on #872 (MySQL) — it's built as a close fork of that module rather than a from-scratch port, since MariaDB and MySQL share almost their entire dialect surface. It also reuses the test data from the MySQL branch.

The biggest difference to MySQL: MariaDB has no LATERAL derived tables in any released version (unlike MySQL, which has had them natively since 8.0.14). So this backend uses the same NotLateral machinery SQLite/H2 use, not MySQL's native-LATERAL rendering — which is also why it has to sit on top of the SQLite PR's SqlMappingLike changes rather than being independent of that work.

Then there's the bit with the driver license:
mariadb-java-client is LGPL 2.1 — a different (and more permissive) license than the MySQL backend's mysql-connector-j (GPLv2 + Universal FOSS Exception). Used the vendor's own connector rather than reusing the MySQL driver via protocol compatibility, since it's the correctly-supported choice and the license is friendlier anyway.

---

Summary

grackle-doobie-mariadb: forked from the already-complete MySQL backend by copying its source tree and renaming, then applying exactly one structural dialect change (mkLateral → NotLateral, see above). Everything else in the dialect started as a byte-identical copy of the MySQL version and was corrected via TDD against a live container wherever a shared-suite test disagreed.

In practice, only one thing needed correcting: MariaDB's JSON type is a LONGTEXT alias, not a native CAST target the way MySQL's JSON type is — CAST(NULL AS JSON) is invalid SQL on MariaDB (ERROR 1064). That case now falls through to a bare NULL instead (same treatment already given to FLOAT/DOUBLE, since an ascribed NULL is only ever an inference hint, not semantically required). This wasn't caught by the shared test suite itself — none of the union/interface suites happen to route a nullable JSON field through that specific ascription path — so it was found by directly probing CAST(NULL AS JSON) against a live MariaDB container during the final review pass, not by a failing test. Everything else needed zero changes: the full 249-test shared suite (same suite class list every other backend wires) is green on both Scala 2.13 and 3.3.8 with that one fix.

Test data — no duplication

The mariadb docker-compose service reuses ./testdata/mysql/ unchanged, via a second bind mount — there's no separate testdata/mariadb/ directory. Verified this actually round-trips correctly (not just assumed dialect-compatible): checked UTF-8 fidelity of the fixture's accented city/country names through the mounted MariaDB container directly, byte-for-byte identical to how they load into MySQL. MariaDB's client didn't turn out to have MySQL's latin1-handshake charset bug, so the entrypoint.sh charset-pin workaround the MySQL backend needs wasn't necessary here.

Version floor

Docker service defaults to mariadb:${MARIADB_VERSION:-lts} — the official image's lts tag always tracks MariaDB's current LTS release (currently 12.3, under MariaDB's newer release policy where the .3 release of each major version is the long-term-support one), so there's no version number to keep re-pinning. Unlike the MySQL backend, there's no independent older-version probe here — no single MariaDB feature analogous to MySQL's "LATERAL since 8.0.14" forces a particular floor, so the floor is simply "developed and tested against current LTS."