This particular loop occurs a lot.
Give it a name and make it concise.
No functional changes.
The goal is to make upcoming changes a bit clearer.

The multi-statement path was subject to both double-frees and leaks.

Having allocs declared once and re-used across loop iterations
made it hard to manage correctly. Reduce its scope to within the
inner closure and defer freeAllocs there.

Even within a loop, it was easy to mismanage; force callers to deal
with this consistently by passing a pointer to newRows and zeroing there.

Take care to Close rows objects from previous iterations when
a subsequent statement in a multi-statement query fails.

The tests here demonstrate both double-frees and
leaked memory without these changes.

I noticed while in this code that in the optimized
single-statement path, there are some unnecessary calls to
reset/clearBindings after newRows. When newRows fails, its internal
defer calls r.Close, which finalizes the prepared statement.
The subsequent reset and clearBindings calls would then operate
on an already-finalized handle. This would be bad, except that
columnCount/columnName cannot fail on a valid pstmt.
Therefore, the error path is dead code.
I didn't touch it, even though pedantically it looks wrong.
There might also be some dangling SQLITE_STATIC references.
Again, this appears to be safe in practice, so I left it alone.
A follow-up could make it conform to the docs
and ensure extra safety.

I don't plan to do any of this follow-up work;
I am focused for now only on demonstrable, directly testable issues.

improve memory safety of allocs in stmt.query

See merge request !96