Move usage docs out of README and into godoc.

Minor style updates to the prose.
Document Error type
Don't tolerate BindComplete after Parse + Describe + Sync

There's no real world scenario where this would happen.
Don't tolerate CommandComplete after Parse + Describe + Sync

Commit 13601feaf94cbd2df4a9b0b752150e08c5885f72 introduced this change,
(after being reported in issue #77), but the problem does not seem to
be with pq misbehaving; the test case itself is to blame.  It does not
correctly close the Rows object before attempting to operate on the
transaction again, which the "Extended query" mode does not like in
the slightest.

The TestRollback test also only tested the simpleQuery path, which
did not have a problem to begin with because it eats the
CommandComplete message from the server if the query returns no
results.  Get rid of the defective test case, and add a new one
testing an error response to the Parse message.
Keep track of the transaction indicator in ReadyForQuery messages

As witnessed in issue #67, previous to this commit pq was happy to
send a COMMIT in a failed transaction (effectively doing a ROLLBACK),
and return a nil error to the caller.  Although one could quite easily
argue that it's the caller's job to make sure that all queries in the
transaction succeeded, it's not really a good idea to return no error
in this case either.  Improve that by keeping track of whether we're
in a failed transaction (or indeed a transaction at all), and fail
explicitly if the caller tried to commit a failed transaction.  This
should also provide increased robustness over protocol-out-of-sync
problems.

It's a bit ugly to have to do this in every code path where a 'Z' is
expected, but the same is true for e.g. ignoring ParameterStatus
messages.  It would be nice to do better than this, but that's a job
for another day.
Check "command tag" after BEGIN, COMMIT and ROLLBACK

This provides additional security against protocol-out-of-sync
errors.  The parsing of the command tag should be similar to what
libpq does.
Add comment explaining what parseCommand does
Add test cases for parseComplete

In passing, also improve comments in parseComplete.
Add comment explaining why we sometimes roll back in Commit

Sending a ROLLBACK here also preserves historical behaviour, sans the
return value.
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.
Fix prepared statements

Prepared statements were inadvertently broken in commit
b7935a1b79fa2dee944d4 by making stmt.Query() re-prepare the statement
every time.
Standardize the internal interface for receiving messages

Previously all callers of recv1 had to remember to explicitly ignore
asynchronous messages, which was quite tedious and error-prone (see
for example #149).  Now recv1 ignores all asynchronous messages (with
the exception of asynchronous ErrorResponse messages) transparently.
If the caller wants to avoid that behaviour, it can either call recv
(which the authentication procedure does) or recvMessage directly.

The only behavioural change should be the use of recv1 in stmt.Close;
the previous coding could have returned an error there for no reason
if an asynchronous message was in the buffer but had not been
processed yet.