With pg8000-1.9.13 passes engine/test_reconnect

The pg8000 dialect checks the text of the exception to determine if the
connection is closed. I'd (recklessly!) changed the text of the
exception in a recent version of the pg8000 driver adding capitalization
and a full stop. I've changed it back now so all works.
PEP8 tidy of test/engine/test_reconnect
Remove spurious print statements in pg8000 dialect
two_phase_recover, COMMIT PREPARED in transaction

In test/engine/test_transaction/test_two_phase_recover(), a COMMIT
PREPARED is issued while in a transaction. This causes an error, and
a prepared transaction is left hanging around which causes
the subsequent test to hang. I've altered the test to execute the
offending query with autocommit=true, then when it gets to the COMMIT
PRPARED it can go ahead.

There's another complication for pg8000 because its tpc_recover() method
started a transaction if one wasn't already in progress. I've decided
that this is incorrect behaviour and so from pg8000-1.9.13 this method
never starts or stops a transaction.
pg8000 now supports sane_multi_rowcount

From pg8000-1.9.14 sane_multi_rowcount is supported so this commit
updates the dialect accordingly.
- port the _collect_insert_commands optimizations from ticket_3100
- mutablemapping adds compiler overhead, so screw it
- max failures 25
- guard against some potential pytest snarkiness
- need list() here for py3k
- support dialects w/o sane multi row count again
Merge remote-tracking branch 'origin/pr/125' into pr125
- changelog for pullreq github:125
- add pg8000 version detection for the "sane multi rowcount" feature
- rework profiling, zoomark tests into single tests so that
they can be used under xdist
- oldest screwup in the book, forgot the file
- Fixed bug where attribute "set" events or columns with
``@validates`` would have events triggered within the flush process,
when those columns were the targets of a "fetch and populate"
operation, such as an autoincremented primary key, a Python side
default, or a server-side default "eagerly" fetched via RETURNING.
fixes #3167
- major simplification of _collect_update_commands.  in particular,
we only call upon the history API fully for primary key columns.
We also now skip the whole step of looking at PK columns and using
any history at all if no net changes are detected on the object.
- organize persistence methods in terms of generators,
narrow down argument lists and generator items for each function
down to just what each function needs.   This will help for them
to be of more multipurpose use for bulk operations
- further reorganize collect_insert_commands to distinguish between
setting up given values vs. defaults.  again trying to shoot for
making this of more general use
- move out checks for table in mapper._pks_by_table
- optimize collection of cols we insert as none