based on feedback in #7271, the emphasis on TypeDecorator
as a solution to this problem is not very practical.  illustrate
a series of quick recipes that are useful for debugging purposes
to print out a repr() or simple stringify of a parameter
without the need to construct custom dialects or types.

Change-Id: I788ce1b5ea01d88dd0a22d03d06f35aabff5e5c8

in order to remove LegacyRow / LegacyResult, we have
to also lose close_with_result, which connectionless
execution relies upon.

also includes a new profiles.txt file that's all against
py310, as that's what CI is on now.  some result counts
changed by one function call which was enough to fail the
low-count result tests.

Replaces Connectable as the common interface between
Connection and Engine with EngineEventsTarget.  Engine
is no longer Connectable.  Connection and MockConnection
still are.

References: #7257
Change-Id: Iad5eba0313836d347e65490349a22b061356896a

Fixes: #7258
Change-Id: I3577f665eca04f2632b69bcb090f0a4ec9271db9

the order_by(None) convention was documented for orm.Query
but not Core select.

Change-Id: I0c1ad76c3eefba1cb54b1649cfd09169c17e2bba

References: #6023

Change-Id: I0f6cbc34b3c0bfc0b8c86b3ebe4531e23039b6c0

Added notes to all TypeEngine methods as to which should be
overridden by TypeDecorator implementations.  Made sure
docstrings are present for all TypeDecorator methods as some
were missing, and clarified which should be overridden, which
should not, as well as what phase each method is called within.

Change-Id: Ibd6e7fb0933ad3ca0927d8785d9087e3eddac90e
References: #7230

these seem to date back to 0.9 and revs like #3148 but none
of it seems to be affecting things now, try removing it all
and seeing what fails.

we've noted that _resolve_label does not appear to be
needed, however allow_label_resolve remains relevant both
for non-column elements like text() as well as that it is
used explicitly by the joined eager loader.

Change-Id: Ic8a5d8001ef2a4133360f51a92a6f7b0cc389095

Fixed regression where the use of a :class:`_orm.hybrid_property` attribute
or a mapped :func:`_orm.composite` attribute as a key passed to the
:meth:`_dml.Update.values` method for an ORM-enabled :class:`_dml.Update`
statement, as well as when using it via the legacy
:meth:`_orm.Query.update` method, would be processed for incoming
ORM/hybrid/composite values within the compilation stage of the UPDATE
statement, which meant that in those cases where caching occurred,
subsequent invocations of the same statement would no longer receive the
correct values. This would include not only hybrids that use the
:meth:`_orm.hybrid_property.update_expression` method, but any use of a
plain hybrid attribute as well. For composites, the issue instead caused a
non-repeatable cache key to be generated, which would break caching and
could fill up the statement cache with repeated statements.

The :class:`_dml.Update` construct now handles the processing of key/value
pairs passed to :meth:`_dml.Update.values` and
:meth:`_dml.Update.ordered_values` up front when the construct is first
generated, before the cache key has been generated so that the key/value
pairs are processed each time, and so that the cache key is generated
against the individual column/value pairs that will ultimately be
used in the statement.

Fixes: #7209
Change-Id: I08f248d1d60ea9690b014c21439b775d951fb9e5