Fix query error handling
Adding Nicolas Patry as contributor

The last commit uses his test case.
Adding Kelly Dunn as contributor

The last fix relies partly on his approach.
Panic on well-defined but unsupported settings

When well-defined settings that are not supported by pq are
present in the environment, we currently ignore them. This
panics instead. Since unexpected values for settings like
PGTZ or PGCLIENTENCODING (which we do not actually support)
could cause data integrity issues, we should complain when
these are present.
Don't panic when settings are as expected

If libpq env vars that we can't allow customization of are
present but set to the values that we need, don't panic--just
ignore them.
Do not pretent we support client_encoding

All pq code assumes (quite sensibly) that PGCLIENTENCODING is UTF-8.
Setting this to an incompatible value can cause protocol integrity
or data integrity issues.
Add encode/decode benchmarks for timestamptz
Home-grown time-parsing to resolve edge cases
Add a test for the RETURNING clause.
Added a test for errors returned during QueryRow
Move benchmark to bench_test.go
Add a few more test cases to the option parser.

Increases code coverage as determined by the new cover tool.
Add origin of parsing code to parseOpts comment.

That way we won't forget if we need to look at it as a reference.
Set all Oids to Oid type.
Adding (and skipping) failing test for #148
Ignore ParameterStatus while waiting for RowDescription or BindComplete

If we happened to receive a ParameterStatus at the right moment, we would
not only fail the current query, but also subsequent ones on the connection
since the server is in a different state than we expect it to be.
Recognize URL as conn string and automagically do the right thing
Ping the database when testing connection option strings

In this particular case the code path wasn't tested at all as
database/sql did not call our Open().
Avoid unnecessary code duplication
Add Marko Tiikkaja to contributors