Convert template_preprocess functions in image module

Reducing scope to image module. there are several, in different include files, so that seems enough on its own.

Not 100% sure on BC for the functions in the include files, there might be some edge cases where that might fail anyway, but kept the pattern for now and moved them to .module.

Used the new closure pattern for the injected logger service, makes it a tiny bit more complicated, but seems like a good compromise for the typical logger-used-in-rare-case scenario and we'd need an Attribute anyway for autowiring.

The performance test fail confused me, I thought we somehow no longer load a config or I had the wrong config name. But that's not it, it's the opposite. Because this is now injected here, it's loaded already on the initial user/login request that warms up bootstrap caches and it's cached afterwards.

I opened #3533322: Do not fetch default image toolkit ID in ImageFactory::__construct() for this.

Updated the comment references in templates that I forgot before. I'd prefer doing the issue in #4 first to avoid the misleading performance test change here.

Initially I considered to drop this pattern with the @see referencing the template/initial preprocess, but got some resistance on that from theme maintainers, so I gave up on that, at least in this scope. It's similar with the docs in twig templates in general, some of these templates have extensive docs that are copy pasted around and tend to get outdated. The default node.html.twig for example has 60 lines of comments and 20 lines of actual markup. And that whole thing exists 11 times in core. And it is at least partially outdated, there's a whole block on default classes, which in fact do not exist but are set within the twig template itself in some cases and not others. Many of us are probably using IDE's or editors that hide that by default and don't even notice it anymore. But I also don't have a great idea on what else we should do. It can be useful for people who are new to Drupal and theming I guess.

We have a generic change record: https://www.drupal.org/node/3504125. but I don't see the point of telling people to update the @see. Nobody is going to do that, that's a lot of tedious work for no real gain. Yeah, in 5 years, if someone looks at a template they won't find that function anymore. But they can just look at the source template, that takes a few seconds, far less time than manually updating all templates.

The soft blocker is in, this can be rerolled and there shouldn't be any performance test changes anymore.

Rebased without the performance stuff

That reminds me, the information when a BC layer is removed does currently not exist in a structured way in change records, that would be way more useful than the branch. Does someone know if an issue exists to add that? Especially now when not everything is being removed for the next major.

I think removing old template_preprocess functions in D12 is one thing, removing support for it might be pretty disruptive. On the other side, BC is built-in and just works (Drupal 11.2+ only looks for a template_ function if no explicit initial preprocess is specified), so it's pretty easy to do that, I recently updated token module accordingly. You don't need a LegacyHook attribute or anything, just leave the old function there and either call the new or just keep it as-is, depending on how much code there is. And it would also make it easier to also deprecate the file and includes keys in hook_theme for D12 (which aren't deprecated yet), because template_preprocess functions is really the only thing they are still used for. We an add an explicit deprecation in either the meta issue or a follow-up of it and finalize that there.

Updating metadata, this in image.module task not a feature.