GeezerVison

RunSql gets byte positions from the editor but used them as character
indices into the QString when checking whether there is anything to
execute. As soon as the text in front of the part to execute contained
multibyte characters, the byte position moved ahead of the character
position, so for the last lines of the SQL code the check looked past
the end of the string, found nothing and silently skipped the
execution ("Execution finished without errors." without any result).

Cut the part to execute out of the UTF-8 encoded query instead, like
the rest of the class already does, and add a test target for RunSql.

Related: sqlitebrowser#3171

RunSql only checked after executing a statement whether it had reached
the end of the part to execute. SQLite skips white space, comments and
empty statements in front of a statement though, so everything left in
the line after its last statement (an additional semicolon, trailing
spaces or a trailing comment) made it prepare and execute the first
statement of one of the following lines as well, and the result of that
one replaced the one of the line. Likewise, executing a line which only
consists of a comment ran the next statement.

Skip these things ourselves before preparing a statement and stop if
nothing else is left in the part to execute.

Also move the calculation of the part to execute for the current line
from MainWindow to RunSql, so it can be tested.

Related: sqlitebrowser#2440

Statements returning data have to be reported as such even if they
return no rows, because otherwise the results table is not updated and
keeps showing the rows of an earlier statement. This was the case for
those which do not start with SELECT, like WITH ... SELECT. It works
now because RunSql looks at the number of result columns of the
prepared statement, so add a test to keep it that way.

Related: sqlitebrowser#1431