- rework the event system so that event modules load after their
targets, dependencies are reversed
- create an improved strategy lookup system for the ORM
- rework the ORM to have very few import cycles
- move out "importlater" to just util.dependency
- other tricks to cross-populate modules in as clear a way as possible

as possible

- went through examples/ and cleaned out excess list() calls

construct after it's been constructed already.  This is not
a pattern for normal use but we like to change the setting
for demonstration purposes in tutorials.

- errant pdbs

- begin consolidating docs for dialects to be more self contained
- add a separate section for "external" dialects
- not sure how we're going to go with this yet.

    when unsupported methods are used inside the
    "execute" portion of the flush.   These are
    the familiar methods add(), delete(), etc.
    as well as collection and related-object
    manipulations, as called within mapper-level
    flush events
    like after_insert(), after_update(), etc.
    It's been prominently documented for a long
    time that  SQLAlchemy cannot guarantee
    results when the Session is manipulated within
    the execution of the flush plan,
    however users are still doing it, so now
    there's a warning.   Maybe someday the Session
    will be enhanced to support these operations
    inside of the flush, but for now, results
    can't be guaranteed.

such as before_flush(), before_update(),
etc. will now function as they would
within non-event code, regarding consideration
of the PK/FK values used in the lazy-emitted
query.   Previously,
special flags would be established that
would cause lazy loads to load related items
based on the "previous" value of the
parent PK/FK values specifically when called
upon within a flush; the signal to load
in this way is now localized to where the
unit of work actually needs to load that
way.  Note that the UOW does
sometimes load these collections before
the before_update() event is called,
so the usage of "passive_updates" or not
can affect whether or not a collection will
represent the "old" or "new" data, when
accessed within a flush event, based
on when the lazy load was emitted.
The change is backwards incompatible in
the exceedingly small chance that
user event code depended on the old
behavior. [ticket:2350]