Change _process_colparams method to remove duplicate isinstance calls
and try to speed up processing of the parameters.

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

Instead of checking multiple times if parameters are a dictionary in the
form of a tuple or list of value pairs, we check it only once and then
store it in the statement so it can be used on compilation time.

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

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.

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

insert statement, :ticket:`3288`, where the column type for the
default-holding column would not be propagated to the compiled
statement in the case where the default was being used,
leading to bind-level type handlers not being invoked.
fixes #3520

with a :class:`.SchemaType` implementation, typically :class:`.Enum`
or :class:`.Boolean` with regards to ensuring that the per-table
events are propagated from the implementation type to the outer type.
These events are used
to ensure that the constraints or Postgresql types (e.g. ENUM)
are correctly created (and possibly dropped) along with the parent
table.
fixes #2919