v0.2.0: SQL, the SQLite importer, and no dependencies

Phase 4 is complete: seven of seven acceptance criteria, each backed by a
test rather than a claim.

What is new since v0.1.1

A SQL front end alongside QQL, lowering onto the same plans, so the
planner, executor and transaction rules are shared. Inner and left joins
with three probe strategies, and begin/commit/rollback across
statements. SQL this dialect does not support is refused by name, with a
position, in a golden test covering 33 constructs.

A SQLite importer that reads the file format directly. No SQLite
library, no C toolchain, no ffi. It reads what SQLite writes, including
tables without rowids, uncheckpointed write-ahead logs, text in utf-16, and
columns added by a later alter table. It runs in two passes: the first
decides what the database becomes and writes nothing, the second executes
that decision, so problems arrive as a report a minute in rather than as a
failure ten minutes into writing.

A command line tool.

quanty import app.sqlite app.qdb
quanty run app.qdb "get users { name } where score > 100"

No dependencies. The checksum and the locks under the storage core are
written out rather than pulled in, so the lock file holds this workspace and
nothing else. What that costs was measured rather than assumed: 1.8
microseconds per 4 KiB page against 1.0 with the CPU instruction. See
ADR-020.

The acceptance runs

Each an hour, on one core:

• SQL parser: 4244088000 inputs parsed, no panic, no broken roundtrip
• SQLite reader: 1831872 damaged and hostile files read, 12 billion cells,
  no panic and no wrong data
• chinook: 15607 rows imported and compared value for value against the
  source, through a reader that is itself checked against SQLite's own
  digests

What this is not yet

Speed is unmeasured. There is no benchmark against SQLite or anything else
in this repo, so no claim is made about performance. There is no server, no
network protocol and no client for any language other than Rust; that is
phase 5.