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

as part of :ticket:`3424` to allow disabling of the MSSQL dialect's
attempts to create aliases for schema-qualified tables, now defaults
to False; the old behavior is now disabled unless explicitly turned on.
fixes #3434

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 a :class:`.types.Enum` or :class:`.postgresql.ENUM` subtype
will now emit the expected "CREATE TYPE" and "DROP TYPE" DDL when
the type is used within a "CREATE TABLE" or "DROP TABLE".
fixes #2729

expression element which is late-evaluated at compile time.  Previously,
the function was only a conversion function which would handle different
expression inputs by returning either a :class:`.Label` of a column-oriented
expression or a copy of a given :class:`.BindParameter` object,
which in particular prevented the operation from being logically
maintained when an ORM-level expression transformation would convert
a column to a bound parameter (e.g. for lazy loading).
fixes #3531