Work around a bug in QueryRow

Unfortunately for us, QueryRow ignores errors from the driver's Next,
which in our case means that it will happily return ErrNoRows if a
run-time error happens while processing an extended query.  Syntax
errors are caught earlier and the simpleQuery path catches the error
earlier, so it's possible that there are applications out there which
are affected by the bug without knowing about it.

To fix, we wait in Query for the first post-BindComplete message to
arrive from the server.  If it's an error, we finish the extended query
procedure inside Query, and return the error.  If it's a
CommandComplete or a DataRow (i.e. the query is likely to succeed),
we memorize the message inside the connection, and return a nil
error from Query.  recv1 then returns the saved message on next call,
presumably to either rows.Next or rows.Close.

It is important to keep in mind that this hack does not fix run-time
errors which happen after the server has sent the first row.  While
that's a lot less common than getting an error before any rows are sent,
it is still a valid concern which all clients should be aware of.  The
documentation should probably be improved to make our users more aware
of the caveats.

There seems to be multiple instances of this bug being reported against
QueryRow; a very quick scan shows at least #148 and #77, but I'm sure
there are others.  Coincidentally, this also fixes the issue reported
in #139, whose workaround (b7935a1b79fa) broke support for prepared
statements.  This should be fixed in a follow-up commit.