Remove prepareToSimpleStmt

It doesn't appear to be serving any purpose, so remove it.
Cache time.Location for Performance

Previously a new time.FixedZone was created for every single time
fetched from the database. This is an immutable structure that is
somewhat expensive to create and so should be cached. Benchmarks
indicate slightly under a 20% speed improvement with a reduction in
allocs from 5 to 2 and a reduction in memory allocated from 213 bytes to
66.
Add Benjamin Heatwole to the list of contributors
Tolerate CommandComplete messages before the data in Simple Query

Commit 1e2ccf84caca692327146254602c580cbf inadvertently broke the case
where one or more CommandComplete messages were received before an
actual result set, as reported in #282 by rylanhalteman.  Revert to the
old behaviour of tolerating any number of CommandComplete messages
before the actual data is received.
Skip test case for issue 282 on Go 1.0

It unfortunately doesn't know about the Queryer interface :-(
Handle EmptyQueryResponses correctly

Like hochhaus noted in #284, we previously didn't handle
EmptyQueryResponses from the server correctly.  Fix by treating them as
a 0-row, 0-column result set.
Fix incorrect parsing of negative time zones
Fix formatting verbs in test error message
Correctly encode time zones with seconds

The previously used RFC3339Nano format to encode times does not take
seconds into account for time zones. This commit fixes that by appending
the time zone seconds to the formatted time, but only if it's non-zero.

Fixes #286
Add Joël Stemmer to the list of contributors
Fix missing call to processReadyForQuery

There was still one place which didn't update the transaction status
indicator based on the ReadyForQuery message.  Prior to this fix, a call
to Commit might have sometimes erroneously complained about the command
tag being ROLLBACK instead of returning the correct error, "Could not
complete operation in a failed transaction".  Though such an application
would have had to ignore a failed query in the first place, which would
explain the lack of bug reports.

Found while investigating a report from Eric Chlebek in #225, though I
can't come up with a scenario where his problem would have been caused
by this.
Don't return ErrBadConn from Open()

Functionality-wise, there's no reason to return ErrBadConn from Open()
since returning *any* error will make sure that the connection is not
put into the pool.  But there's a very good reason not to return
ErrBadConn; it makes diagnosing problems during connection establishment
completely impossible without either having access to the server logs or
interpreting captured network traffic.

This is a minor backwards compatibility breakage, since we used to
return ErrBadConn in a lot of cases previously.  However, there were
several cases were we returned the real error instead, so any caller
assuming that they would either get a nil or ErrBadConn from Open was
already broken.

Based on initial work from Paul Jolly, after discussions with Paul and
Eric Chlebek.
Remove dead code

This code has been dead since b7935a1b79fa2dee944d464273356dd3.
Support arbitrary network dialers

One such use case is to use the library within the constraints of Google
App Engine
https://developers.google.com/appengine/docs/go/sockets/reference
Add Fumin to the list of contributors
Fix problem with explicit transactions and ErrBadConn

Because database/sql ignores ErrBadConn from all *Tx methods, a bad
connection might have been put back into the pool thinking it's in a
transaction.  This connection would then on the next call to Begin()
return the error "pq: unexpected transaction status in a failed
transaction", and then be put back into the pool, again.  With bad
enough luck the pool might get filled with these connections, and the
application wouldn't be able to start any transactions, effectively
rendering it useless :-(

To fix, we have no option other than to remember when a connection is
bad, and return ErrBadConn for such connections from any method
database/sql might call.
Mark the connection bad if the server responds with something unexpected

Commit 07745050691bbe88ce770ca38311c19be9445e37 allows us to return an
error message while still marking the connection bad.  Use that to our
advantage in cases where the protocol state appears to be out of sync.
This way the user still sees the specific error message (and hopefully
we'll see a bug report), but we avoid putting bad connections into the
pool thinking they're still A-ok.
Display a nicer error when a query is run with more than 2^16-1 params

Because the number of parameters in the wire protocol is an uint16,
there's no way to execute a prepared statement with more than 2^16-1
parameters.  Display a nicer error message in that case.

The error will still be a bit obscure if the user explicitly prepared
the statement, though, since database/sql will be the one complaining in
that case.

I also deliberately did not commit a test case for this, since running
the test I wrote took more than 20 seconds on my laptop, which isn't
justifiable for a corner case like this.  I've left my test case into
issue #295.

Per complaint from Brian Fallik in the same issue.
Remove superfluous type conversion
Remove superfluous errRecover from simpleExec

All of its callers are already recovering from errors (like they should
be), so this is just unnecessary overhead.