- 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

- break out key mechanics of loading objects
into new "orm.loading" module, removing implementation
details from both mapper.py and query.py. is analogous
to persistence.py
- some other cleanup and old cruft removal

such as ``.. versionadded::``, ``.. versionchanged::`` and ``.. deprecated::``.

for multiprocessing compatibility. [ticket:2371]

- remove() on a scalar object will raise if the object
removed is not what was present.
- InstanceState can be pickled if obj() is None; this
to support the other changes in this commit
- only use trackparent flag on attributes if
single_parent or ONETOMANY; otherwise we can skip this
overhead
- attribute hasparent()/sethasparent() check that trackparent
is set, else their usage is invalid
- [bug] Fixed backref behavior when "popping" the
value off of a many-to-one in response to
a removal from a stale one-to-many - the operation
is skipped, since the many-to-one has since
been updated.  [ticket:2315]

- [bug] After some years of not doing this, added
more granularity to the "is X a parent of Y"
functionality, which is used when determining
if the FK on "Y" needs to be "nulled out" as well
as if "Y" should be deleted with delete-orphan
cascade.   The test now takes into account the
Python identity of the parent as well its identity
key, to see if the last known parent of Y is
definitely X.   If a decision
can't be made, a StaleDataError is raised.  The
conditions where this error is raised are fairly
rare, requiring that the previous parent was
garbage collected, and previously
could very well inappropriately update/delete
a record that's since moved onto a new parent,
though there may be some cases where
"silent success" occurred previously that will now
raise in the face of ambiguity.
Expiring "Y" resets the "parent" tracker, meaning
X.remove(Y) could then end up deleting Y even
if X is stale, but this is the same behavior
as before; it's advised to expire X also in that
case.  [ticket:2264]

where row can't be located raises
ObjectDeletedError instead of failing later
on; improved the message in ObjectDeletedError
to include other conditions besides a simple
"delete". [ticket:2191]
- break up test_get_refreshes() in test_expire