Query runs: state of one run kept on the cached statement, and separate sync and async paths #2724

Several bugs come from where a query keeps the state of one run and from having separate synchronous and asynchronous code paths. Values that belong to one run (parameters used as LIMIT, subquery caches) are written to the compiled statement that the cache shares between runs, and each kind of source (tables, ?, subqueries, files) reads its rows and reports its errors in its own way. Bugs traced to this:

• Run state on the cached statement: Cached statements hold per-run state, so two runs of the same SQL at once overwrite each other #2596, Set operation with ORDER BY / LIMIT on the first SELECT gives a different result from the second run #2605, Review #2534 for code improvements: parameters for subqueries in UPDATE #2632, Review #2281 for code improvements: IN subquery caching decided per row #2645, Review #2517 for code improvements: LIMIT and OFFSET parameters written into the compiled query #2667
• Options left out of the cache key: Review #2312 for code improvements: one option in the statement cache key #2652
• Synchronous and asynchronous paths that differ: Read a subquery in JOIN the same way as in FROM, so it can read a file #2676, Review #2349 for code improvements: UPDATE, DELETE and INSERT on ? build a temporary table each run #2682, Let BREAK and CONTINUE work in a WHILE loop run asynchronously #2701
• File sources that report errors differently: Fix JSON file error handling #2513, Review #2082 for code improvements: each file source handles its own errors #2677