(*conn).bind scanned every argument for every statement parameter, so
binding n parameters took O(n^2) comparisons: a multi-row INSERT with 20k
positional parameters spent almost all of its time there. database/sql
passes args with args[j].Ordinal == j+1, so the argument for ordinal k is
args[k-1]; ?, ?NNN and $NNN parameters now go there directly and named
parameters through a name index built once per call above 32 arguments,
below which scanning measured faster and allocation-free. Anything else
takes the old scan, kept as scanArgs, so every parameter gets the argument
it got before; TestArgFinder checks that against scanArgs.

The reporter's reproducer on linux/amd64 goes from 5939 ms to 200 ms at
370 rows (19980 parameters) per statement. With thousands of ?NNN, $NNN or
named parameters SQLite itself stays quadratic, in parsing and in
sqlite3_bind_parameter_name, which walk its linear VList of names.

Verified: go test -short . (446 s), the binding tests on GOARCH=386,
staticcheck and golint add no findings.

Reported in https://github.com/modernc-org/sqlite/issues/8.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>