This patch contains a variety of ORM and expression layer
tweaks to support ORM constructs in select() statements,
without the 1.3.x requiremnt in Query that a full
_compile_context() + new select() is needed in order to
get a working statement object.

Includes such tweaks as the ability to implement
aliased class of an aliased class,
as we are looking to fully support ACs against subqueries,
as well as the ability to access anonymously-labeled
ColumnProperty expressions within subqueries by
naming the ".key" of the label after the property
key.   Some tuning to query.join() as well
as ORMJoin internals to allow things to work more
smoothly.

Change-Id: Id810f485c5f7ed971529489b84694e02a3356d6d

Convert Query to do virtually all compile state computation
in the _compile_context() phase, and organize it all
such that a plain select() construct may also be used as the
source of information in order to generate ORM query state.
This makes it such that Query is not needed except for
its additional methods like from_self() which are all to
be deprecated.

The construction of ORM state will occur beyond the
caching boundary when the new execution model is integrated.

future select() gains a working join() and filter_by() method.
as we continue to rebase and merge each commit in the steps,
callcounts continue to bump around.  will have to look at
the final result when it's all in.

References: #5159
References: #4705
References: #4639
References: #4871
References: #5010

Change-Id: I19e05b3424b07114cce6c439b05198ac47f7ac10

Fixed an additional regression in the same area as that of :ticket:`5080`
introduced in 1.3.0b3 via :ticket:`4468` where the ability to create a
joined option across a :func:`.with_polymorphic` into a relationship
against the base class of that with_polymorphic, and then further into
regular mapped relationships would fail as the base class component would
not add itself to the load path in a way that could be located by the
loader strategy. The changes applied in :ticket:`5080` have been further
refined to also accommodate this scenario.

Fixes: #5121
Change-Id: I9753dbbcb7b7640c995ad983a6d04b36fa18cf54

Fixed regression caused in 1.3.13 by :ticket:`5056` where a refactor of the
ORM path registry system made it such that a path could no longer be
compared to an empty tuple, which can occur in a particular kind of joined
eager loading path.   The "empty tuple" use case has been resolved so that
the path registry is compared to a path registry in all cases;  the
:class:`.PathRegistry` object itself now implements ``__eq__()`` and
``__ne__()`` methods which will take place for all equality comparisons and
continue to succeed in the not anticipated case that a non-
:class:`.PathRegistry` object is compared, while emitting a warning that
this object should not be the subject of the comparison.

Fixes: #5110
Change-Id: I6cab6cd771c131d12b17939b369212f12c6bee16

Fixed regression in loader options introduced in 1.3.0b3 via :ticket:`4468`
where the ability to create a loader option using
:meth:`.PropComparator.of_type` targeting an aliased entity that is an
inheriting subclass of the entity which the preceding relationship refers
to would fail to produce a matching path.   See also :ticket:`5082` fixed
in this same release which involves a similar kind of issue.

Fixes: #5107
Change-Id: I5c6717b925060c3f8da42190d1f00d05248befd8

We must change the approach from 2734439 as the information
loss is breaking subquery eager loading.

Move the adjustment into a deeper set of logic inside
of path_regsitry.  We can distinguish between a path
that will "naturally" build from an aliased entity
at the base, vs. one that will "naturally" build
on all raw mappers, based on if when we observe that
we are being given a with_polymorphic(), if the existing
parent path is already in progress or not.

In general, we prefer paths to have as much of the original
information as possible, and the "natural path" is supposed
to be where the loader lookup stuff happens.

Fixes: #5082
Change-Id: I3c0ee72993bae8a6f067bdef3dc9a57d83f64950

Fixed regression in joined eager loading introduced in 1.3.0b3 via
:ticket:`4468` where the ability to create a joined option across a
:func:`.with_polymorphic` into a polymorphic subclass using
:meth:`.RelationshipProperty.of_type` and then further along regular mapped
relationships would fail as the polymorphic subclass would not add itself
to the load path in a way that could be located by the loader strategy.  A
tweak has been made to resolve this scenario.

Fixes: #5082
Change-Id: I1c7b8d70ed94436c655e433bf34394b13d384c35

Added test support and repaired a wide variety of unnecessary reference
cycles created for short-lived objects, mostly in the area of ORM queries.

Fixes: #5056
Change-Id: Ifd93856eba550483f95f9ae63d49f36ab068b85a

In the interests of making Query much more lightweight up front,
rework the calculations done at the top when the entities
are constructed to be much less inolved.  Use the new
coercion system for _ColumnEntity and stop accepting
plain strings, this will need to emit a deprecation warning
in 1.3.x.     Use annotations and other techniques to reduce
the decisionmaking and complexity of Query.

For the use case of subquery(), .statement, etc. we would like
to do minimal work in order to get the columns clause.

Change-Id: I7e459bbd3bb10ec71235f75ef4f3b0a969bec590

Fixed bug where :class:`.Load` objects were not pickleable due to
mapper/relationship state in the internal context dictionary.  These
objects are now converted to picklable using similar techniques as that of
other elements within the loader option system that have long been
serializable.

Fixes: #4823
Change-Id: Id2a0d8b640ac475c86d6416ad540671e66d410e5