fix(sqlite): translate antlr rune offsets to byte offsets

[abgoyal]

Summary

Fixes a bug where SQLite code generation produced truncated or corrupt
output whenever the source .sql file contained a non-ASCII character
(em-dash, accented letters, etc.).

The bug

Given a query with a multi-byte character in a comment (here the é in
"café", which is 2 bytes in UTF-8):

-- name: GetItem :one
-- Lookup used by the café menu screen
SELECT id, name FROM items WHERE id = ?;

sqlc generated a truncated SQL constant, dropping the trailing ?:

const getItem = `-- name: GetItem :one
SELECT id, name FROM items WHERE id =
`

In queries that use sqlc.arg() or SELECT *, the misaligned offsets
caused edits to land at the wrong byte positions and produced SQL that
fails to parse (e.g. SEid ...). There was no error at generate time —
the corruption was silent.

Root cause

antlr's InputStream stores the input as a []rune and reports all
token positions as rune indices. The rest of sqlc, shared with the
Postgres and MySQL engines, treats query offsets as byte offsets
into the original source:

• source.Pluck slices the raw SQL for each statement
• source.Mutate applies parameter / star-expansion edits

For ASCII, rune index == byte offset, so the bug never surfaced. A
multi-byte rune (em-dash = 3 bytes, 1 rune) makes every later rune
index lag its true byte offset, truncating the statement slice and
shifting every edit. Postgres and MySQL are unaffected because they get
byte offsets from libpg_query and TiDB.

The fix

Confined to the SQLite engine. We build a rune-index → byte-offset table
for the source and translate offsets at the point they are produced, so
a rune-based offset never escapes the parser:

• parse.go converts the statement's StmtLocation / StmtLen and
  threads the table into the converter (cc.convertPos).
• convert.go routes every node Location through a single cc.pos
  helper instead of using the raw antlr token offset.

By the time the AST leaves the parser, all offsets are byte offsets,
matching the invariant the other engines already satisfy. The
translation lives where the offsets originate, so there is no separate
post-processing pass and no reflection.

Testing

• New regression test internal/engine/sqlite/parse_test.go (fails
  before the fix, passes after).
• Verified sqlc generate end-to-end on the query above and on a harder
  case (multi-byte string literal before sqlc.arg() params +
  SELECT *); both are correct after the fix, and the latter produced
  corrupt SQL before it.

[Nthalk]

Carrying the same fix in a fork, and this PR matches what we ended up with. Two
notes from reviewing it.

The test doesn't cover the convert.go half. Revert just this line in parse.go:

converter := &cc{convertPos: runeToByte}   ->   converter := &cc{}

and TestParseNonASCIIOffsets still passes. It only asserts through source.Pluck,
which exercises StmtLocation/StmtLen. So it can't tell this PR apart from #4314
and #4373, which patch parse.go only.

Those two are incomplete, which is the other note: node Locations stay rune
offsets while StmtLocation becomes bytes, and expand.go:195 does
res.Location - raw.StmtLocation. Mixed units.

The convert.go half is also where the silent failure lives. Truncation breaks
loudly. A misplaced star expansion can still parse, so sqlc exits 0 and the
generated Go only fails at runtime:

SELECT 'café' AS tag, * FROM item;
SELECT 'café' AS tag,id, name* FROM ite

That reads ResTarget.Location.

I have a test that catches it. It checks each location by slicing the source at
it and comparing the token, over six cases including the one above and a
multibyte char in an earlier statement. Passes on your branch, fails 5 subtests
with convertPos nil. Want it as a PR against your branch?