- 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
- The :class:`.IdentityMap` exposed from :class:`.Session.identity`
now returns lists for ``items()`` and ``values()`` in Py3K.
Early porting to Py3K here had these returning iterators, when
they technically should be "iterable views"..for now, lists are OK.
- proof of concept
dev
- change to be represented as two very fast bulk_insert() and bulk_update() methods
- refine this enough so that _collect_insert_commands() seems
to be more than twice as fast now (.039 vs. .091); bulk_insert()
and bulk_update() do their own collection but now both call into
_emit_insert_statements() / _emit_update_statements(); the approach
seems to have no impact on insert speed, still .85 for the
insert test