looks like mypy 1.1.1 slipped in after the last jenkins pep484 build
for SQLAlchemy.  update for its new issues.

Change-Id: Ifca967a75d5e592c04b0138aeda9b646067fe59b

The typing change in ba0e508141206efc55cdab91df21c1
changed the semantics of pop() and possibly setdefault() in order to
try working at runtime with a two-argument signature.  however
the implementation for this in cpython likely uses a strict `*args`
approach where the lack of the second parameter is explicit, rather
than matching to a constant.  Restore the old implementation inside
of a "not TYPE_CHECKING" block while keeping the type annotated forms
intact for typing only.

Fixed regression caused by typing added to ``sqlalchemy.ext.mutable`` for
:ticket:`8667`, where the semantics of the ``.pop()`` method changed such
that the method was non-working.  Pull request courtesy Nils Philippsen.

Fixes: #9380
Closes: #9381
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9381
Pull-request-sha: fd903ce1b949d2af26ceb6c2159ad84aab007f3d

Change-Id: I213e52f51a795801aacf05307e38cc8c89b54e12

Fixed bug where the :meth:`_engine.Connection.scalars` method was not typed
as allowing a multiple-parameters list, which is now supported using
insertmanyvalues operations.

Change-Id: I65e22c3bee80fc226d484ff1424421dd78520fa5

Add separate 1.4.24 and 1.4.26 version notes for the .scalars method;
this covers Session, scoped_session, AsyncSession, async_scoped_session
as the "scoped" versions did not have the method added until 1.4.26
as part of :ticket:`7103`.

Also indicate scoped_session as ``sqlalchemy.orm.scoped_session`` in
docs rather than ``sqlalchemy.orm.scoping.scoped_session``.  This is
also happening in I77da54891860095edcb1f0625ead99fee89bd76f separately,
as both changesets refer to scoped_session without using ".scoping".

References: #7103
Closes: #9371
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9371
Pull-request-sha: 61132230cc6e897ab61beff25d98b19a4c0aefd0

Change-Id: I84c8b1aad752db124cfee6bc8516f6eed7ba2faf

Fixed issue in automap where calling ``.prepare()`` from one of the mapped
classes would not use the correct base class when automap detected new
tables, instead using the given class, leading to mappers trying to
configure inheritance. While one should normally call ``.prepare()`` from
the base in any case, it shouldn't misbehave that badly when called from a
subclass.

Fixes: #9367
Change-Id: I705d4d939d45af52bc58a74e65994205ab791634

I can only see issues in the docs when they're live on the
site, sorry

Change-Id: I948b7c8e37657ca85d02843211cbfdb03aa5da75

Change-Id: I547e66b60f5a7b2901a76ebc59469bce018e05ff