Recursion in EXEC_SQL request handling

[cole-miller]

Copying the description from #697

Recall that the issue arises with a call stack like this (callees at the top)

handle_exec_sql_next
handle_exec_sql_cb
leaderExecV2
leader__barrier
leader__exec
handle_exec_sql_next
...

that is, indirect recursion that can generate a number of stack frames proportional to the number of ;-separated statements in an EXEC_SQL request. This happens because leader__barrier and leader__exec can invoke their callbacks synchronously when suspending is not required (respectively, because the FSM is up to date with the raft log and and because sqlite3_step generated no changed pages).