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.
add update() support to MutableDict
fix MutableDict.coerce

If a class inherited from MutableDict (say, for instance, to add an update() method), coerce() would give back an instance of MutableDict instead of an instance of the derived class.
- updates
on second thought we need to prioritize what really needs to be
here and what's just in changelog
pep8
- Removing (or adding) an event listener at the same time that the event
is being run itself, either from inside the listener or from a
concurrent thread, now raises a RuntimeError, as the collection used is
now an instance of ``colletions.deque()`` and does not support changes
while being iterated.  Previously, a plain Python list was used where
removal from inside the event itself would produce silent failures.
fixes #3163
- The string keys that are used to determine the columns impacted
for an INSERT or UPDATE are now sorted when they contribute towards
the "compiled cache" cache key.   These keys were previously not
deterministically ordered, meaning the same statement could be
cached multiple times on equivalent keys, costing both in terms of
memory as well as performance.
fixes #3165
pep8
pep8
- UPDATE statements can now be batched within an ORM flush
into more performant executemany() call, similarly to how INSERT
statements can be batched; this will be invoked within flush
to the degree that subsequent UPDATE statements for the
same mapping and table involve the identical columns within the
VALUES clause, as well as that no VALUES-level SQL expressions
are embedded.
- some other inlinings within persistence.py
- modify how class state is tracked here as it seems like things
are a little more crazy under xdist mode
- other test fixes
- don't add the parent attach event within _on_table_attach
if we already have a table; this prevents reentrant calls and
we aren't supporting columns/etc being moved around between different parents
- clean up provision and keep sqlite on memory DBs if thats what we start with
- TIL that dict.keys() in py3K is not an iterator, it is an iterable
view.  So copy collections.OrderedDict and use MutableMapping to set up
keys, items, values on our own OrderedDict.

Conflicts:
	lib/sqlalchemy/engine/base.py