[WIP] SQLAlchemy 2.0 follow-up: misc. improvements

[jdavcs]

(Please replace this header with a description of your pull request. Please include BOTH what you did and why you made the changes. The "why" may simply be citing a relevant Galaxy issue.)
(If fixing a bug, please add any relevant error or traceback)
(For UI components, it is recommended to include screenshots or screencasts)

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[jdavcs]

We have 168 model classes most of which have the same id column. So, following SA docs, we factor out the common column into a mixin:

class HasId:
    id: Mapped[int] = mapped_column(primary_key=True)

class Foo(HasId):
   ...
   bar = relationship(..., remote_side=[id])

However, this will cause errors when that column is used to specify other properties in a class. In the example above, the id identifier will resolve to Python's builtin id whenever it is used to specify a relationship in Foo. So this won't work. I'll check if there are recommended best practices, and if not, we'll just have to stick with defining all columns in each class.

Another neat refactoring that doesn't always work. If we replace foo: Mapped[str] = mapped_column() with foo = Mapped[str], because that's sufficient for mapping and is recommended as per SA docs, we won't be able to use foo to specify things like column properties, because without mapped_function() it won't exists at that time. So this won't work:

first: Mapped[str] = mapped_column()
last: Mapped[str]
full: column_property(first + " " + last)  # last doesn't exist yet!

I'll check for more info on the above, but overall, I think, we should be cautious in applying SA 2.0 model definition syntax optimizations.

UPDATE: it seems to be as simple as using the callable form for foreign_keys and remote_side. Waiting for tests now.