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.
Make the handling of driver-only settings more consistent

There seemed to be two different ways these were handled.  Pick one of
them and embrace it.
Add support for sslcert and sslkey

This commit adds support for both automatically loading certificates
from ~/.postgresql/ and loading them from arbitrary paths by using
sslcert and sslkey (or their environmental equivalents PGSSLCERT and
PGSSLKEY).  If their paths are set explicitly, the files must exist or
connection attempts will fail.  The behaviour was designed to exactly
match that implemented by libpq.

Also add some basic testing for SSL features into Travis.  Previously
the SSL support was not tested at all.  The tests are not run unless
some special environment variables are set, since we can't run these
tests without special support.

James Pozdena (@jpoz) and Marko Tiikkaja (@johto).
Add James Pozdena to the list of contributors
Calculate the distro codename for APT
Add support for sslrootcert option and PGSSLROOTCERT env. variable
Fix documentation for sslcert / sslkey

All of the parameters are optional, so there's no need to mention it
separately for these two.
Add Charlie Melbye to the list of contributors
Add support for sslmode=verify-ca

This is like verify-full, except the Common Name isn't matched against
the "host" parameter.
Move environment variables to the env configuration
Fix setup for SSL tests in Travis CI