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.
Avoid unnecessarily ignoring asynchronous messages

Commit 7454a9817b0f148ab5b1 looks to have fixed all callers of recv1
except this one.
Improve robustness of Begin, Rollback and Commit

Commits 46e935d341c15691dfb2614375 and 44ea1b5c0bf9099acec9e6c5f1
made the transactions handling functionality more robust, but we
can do a bit better than that by also checking the ReadyForQuery
state after these commands.

They also made it possible for the functions to panic, which is not
a good idea (see #178).  Guard against that with errRecover.
Check the number of supplied parameters against what the statement expects

Panicking here is not a good idea, and an explicit error message should
be a lot more helpful to the user as well.
Fix handling of CommandComplete response to SimpleQuery

The previous coding in simpleQuery was slightly misguided; it was
written under the assumption that CommandComplete would only be
sent after ErrorResponse, which, as pointed out in #186, is simply
not true.  CommandComplete should only be received there as a
response to a query which was successfully executed, but did not
return any results.  This also means that we return a nil error
*and* a nil rows to database/sql, which would either panic (if the
user calls Rows.Close), or leak the connection (if he doesn't).

While any program using Query to execute such queries will likely
be experiencing problems already, there's no reason to completely
break them.  To fix the problem, we return a rows object which has
its "done" flag already set to allow the user to close the Rows
object from database/sql to avoid leaking connections.  Also add a
test case to check that we consistently allow both types of queries
through both Query and Exec, both with and without parameters.
Support the "escape" bytea format when receiving data

This allows pq to operate correctly in both output formats, which
should help users who are still on PG 9.0 or have resorted to
setting bytea_output to "escape" for other reasons.

Even after this commit, bytea data is always sent in the "hex"
format.  This is not a problem for PostgreSQL versions 9.0 and later
as they are guaranteed to accept either format.  Older versions will
continue to experience problems, but it's not clear whether that
problem is worth fixing or not.
Merge pull request #195 from johto/bytea_escape

Support bytea_output=escape when receiving data
Add test for issue #196
Improved precision encoding support for float32 and float64

This ensures that all IEEE754 single and double precision floating
point values retain their full fidelity when submitted as parameters.