Remove added dict comprehensions that make this patch set non python 2.6
compatible.

Postpone as much as possible the change of update parameters to
OrderedDict from list or tuple of pairs.

This way we won't have problems with query's update method.

To avoid penalties for updates that do not require ordering, we will
only use OrderedDict for updates that receive a tuple or list of pairs,
and all kinds of dictionaries (dict, sqlalchemy's OrderedDict, or
collections.OrderedDict) will be treateated as unordered updates, just
like we were doing before.

This way this new feature will not change how updates behave for any
existing code and will only affect those that use the new ordered
feature.

This patch reverts update tests to how they were before as well as adds
a couple of tests to confirm that OrderedDicts are really treated like
normal dicts.

In some DBs the UPDATE operation is order dependent, so the operation
behaves differently depending on the order of the values.

As an example, imagine a volumes table with columns 'status' and
'previous_status' and we want to update a volume that has 'available' in
the status column.

If the SQL query is performed as:

 UPDATE volumes SET previous_status=status, status='new' WHERE id=1;

This will result in a volume with 'new' status and 'available'
previous_status both on SQLite and MariaDB, but if we reverse the
columns:

 UPDATE volumes SET status='new', previous_status=status WHERE id=1;

We will get the same result in SQLite but will result in a volume with
status and previous_status set to 'new' in MariaDB, which is not what we
want.

So order must be taken into consideration in some cases and it should be
allowed to ve specified via the Query update method or the values method
of an update.

This patch fixes this issue by preserving the order of parameters in
updates and allowing to receive not only dictionaries in update and
values but also ordered dictionaries and list/tuples of value pairs
(like dict and OrderedDict do).

fixes #3541

:meth:`.Session.bulk_save_objects` and related bulk methods have
been scaled back to the extent that this functionality is not
currently used, e.g. checks for column default values to be
fetched after an INSERT or UPDATE statement.
fixes #3526

column that had some kind of "fetch on update" value and was not
locally present in the given object would cause an AttributeError
within the operation.
fixes #3525

- Fixes to the ORM and to the postgresql JSON type regarding the
``None`` constant in conjunction with the Postgresql :class:`.JSON` type.  When
the :paramref:`.JSON.none_as_null` flag is left at its default
value of ``False``, the ORM will now correctly insert the Json
"'null'" string into the column whenever the value on the ORM
object is set to the value ``None`` or when the value ``None``
is used with :meth:`.Session.bulk_insert_mappings`,
**including** if the column has a default or server default on it.  This
makes use of a new type-level flag "evaluates_none" which is implemented
by the JSON type based on the none_as_null flag. fixes #3514
- Added a new constant :attr:`.postgresql.JSON.NULL`, indicating
that the JSON NULL value should be used for a value
regardless of other settings. part of fixes #3514

``__eq__()`` to return a non-boolean-capable object, such as
some geoalchemy types as well as numpy types, were being tested
for ``bool()`` during a unit of work update operation, where in
0.9 the return value of ``__eq__()`` was tested against "is True"
to guard against this.
fixes #3469

feature would cause an object's version counter to be incremented
when there was no net change to the object's row, but instead an object
related to it via relationship (e.g. typically many-to-one)
were associated or de-associated with it, resulting in an UPDATE
statement that updates the object's version counter and nothing else.
In the use case where the relatively recent "server side" and/or
"programmatic/conditional" version counter feature were used
(e.g. setting version_id_generator to False), the bug could cause an
UPDATE without a valid SET clause to be emitted.
fixes #3465

to suit #3451 exclude these columns from the "params"
dictionary in the first place, revises pr github:181