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

kinds of internal column loader options within internal logging.
fixes #3539

which indicates to the ORM that a positive set of None should be
persisted as the value NULL, instead of omitting the column from
the INSERT statement.  This feature is used both as part of the
implementation for :ticket:`3514` as well as a standalone feature
available on any type.  fixes #3250
- add new documentation section illustrating the "how to force null"
 use case of #3250
- alter our change from #3514 so that the class-level flag is now
called "should_evaluate_none"; so that "evaluates_none" is now
a generative method.

to use mapper.cascade_iterator() for this purpose as it was not really
designed for that use case.  Add docs to cascade_iterator() pointing
to the recipe.  fixes #3498

: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