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.
Add Matt Newberry to Contributors
Use a transaction in TestByteaOutputFormats

This avoids relying on getting the same connection for consecutive
queries from database/sql.
Add Go 1.2 to .travis.yml
Add extra_float_digits issue test
Set extra_float_digits to preserve float fidelity.

Without this setting, it's easy to lose fidelity when round-tripping data.
Automate OID table generation

Also document type Oid separately, and update
OID table to the Postgres 9.3 version.
Specify sizes for the floats in TestIssue196

float32 wasn't being tested at all.
Bump down extra_float_digits to 2

This is to avoid breaking 8.4 in preparation for fully supporting it
in an upcoming patch (see #199).

Note that the tests here do not correctly check for a required
extra_float_digits=3, since they still pass; this should be
reviewed further.
Send bytea values in "escape" format to old servers
Don't look at AffectedRows in SELECT for pre-9.0 servers

It looks like the number of rows affected by SELECT was not part of
the command tag before version 9.0, though I can't see a mention of
it in the release notes.
Don't try to run TestByteaOutputFormats against old servers
Remove usage of DO in test cases
Add tests for 8.4
Adding Hstore support package
Add Jeremy Jay to Contributors
Try to infer the time zone for timestamptzs from TimeZone

When receiving a "timestamp with time zone" value from the database
we try to set its time zone based on the current value of TimeZone.
If, and only if, the offset we got from the local time zone database
matches the offset we got from the server, we return the new value
with time zone information.  This way the user always gets the time
as the database sent it (even if the local database is not in sync
with the remote one), which maintains backwards compatibility and
avoids confusion.

This should currently work correctly in all cases, but if we ever
start supporting multiple simultaneous queries, we will have to be
careful to use the correct TimeZone value for each of them.