exprssed -> expressed

now skip textual label references when copying ORDER BY elements
to the joined-eager-load subquery, as we can't know that these
expressions are compatible with this placement;  either because
they are meant for text(), or because they refer to label names
already stated and aren't bound to a table. fixes #3392

passed as a keyword argument to the :meth:`.DDLEvents.before_create`,
:meth:`.DDLEvents.after_create`, :meth:`.DDLEvents.before_drop`, and
:meth:`.DDLEvents.after_drop` events would no longer be a list
of tables, but instead a list of tuples which contained a second
entry with foreign keys to be added or dropped.  As the ``tables``
collection, while documented as not necessarily stable, has come
to be relied upon, this change is considered a regression.
Additionally, in some cases for "drop", this collection would
be an iterator that would cause the operation to fail if
prematurely iterated.   The collection is now a list of table
objects in all cases and test coverage for the format of this
collection is now added.
fixes #3391

event where its invocation was moved to be after the class manager's
instrumentation of the class, which is the opposite of what the
documentation for the event explicitly states.  The rationale for the
switch was due to Declarative taking the step of setting up
the full "instrumentation manager" for a class before it was mapped
for the purpose of the new ``@declared_attr`` features
described in :ref:`feature_3150`, but the change was also made
against the classical use of :func:`.mapper` for consistency.
However, SQLSoup relies upon the instrumentation event happening
before any instrumentation under classical mapping.
The behavior is reverted in the case of classical and declarative
mapping, the latter implemented by using a simple memoization
without using class manager.
fixes #3388

changes made to the :class:`.Query` object's collection of entities
to load within the event would render in the SQL, but would not
be reflected during the loading process.
fixes #3387

(hence becoming two regressions); reports that
SELECT statements would GROUP BY a label name and fail was misconstrued
that certain backends such as SQL Server should not be emitting
ORDER BY or GROUP BY on a simple label name at all; when in fact,
we had forgotten that 0.9 was already emitting ORDER BY on a simple
label name for all backends, as described in :ref:`migration_1068`,
as 1.0 had rewritten this logic as part of :ticket:`2992`.

In 1.0.2, the bug is fixed both that SQL Server, Firebird and others
will again emit ORDER BY on a simple label name when passed a
:class:`.Label` construct that is expressed in the columns clause,
and no backend will emit GROUP BY on a simple label name in this case,
as even Postgresql can't reliably do GROUP BY on a simple name
in every case.
fixes #3338, fixes #3385

fixes #3383

and ``__declare_last__`` accessors where these would no longer be
called on the superclass of the declarative base.
fixes #3383