Closes #2934

Have also considered linking column.label() to the "column" itself being
in the result map but this reveals some naming collision problems (that
also seem to be very poorly tested...).   This should be as far as
we want to go right now with [ticket:2932].

raise the :class:`.InvalidRequestError` that invokes when called
on a query with existing criterion, when the given identity is
already present in the identity map. [ticket:2951]

to a base class such as a declarative base with the propagate=True
flag would fail to apply to existing mapped classes which also
used inheritance due to an assertion.  Addtionally, repaired an
attribute error which could occur during removal of such an event,
depending on how it was first assigned. [ticket:2949]

new automap extension would fail if classes
were pre-arranged in single or potentially joined inheritance patterns.
The repaired joined inheritance issue could also potentially apply when
using :class:`.DeferredReflection` as well.

using a column key of the form ``<tablename>_<columnname>``
matching that of an aliased column in the text would still not
match at the ORM level, which is ultimately due to a core
column-matching issue.  Additional rules have been added so that the
column ``_label`` is taken into account when working with a
:class:`.TextAsFrom` construct or with literal columns.
[ticket:2932]

constructs would fail if the bind were constructed with a callable,
rather than a direct value.  This prevented ORM expressions
from being rendered with the "literal_binds" compiler flag.

calling ``MyClass.attribute`` will not require that the configure
mappers step has occurred, e.g. it will just work without throwing
any error. [ticket:2935]