Use logger channel services consistently, instead of the factory object

@longwave (#3)

My longer-term thinking on this also ties into autowiring. We can't autowire loggers directly because different services want to use different channels. But eventually we can use argument binding like this in e.g. user.services.yml:

services:
  _defaults:
    autowire: true
    bind:
      Psr\Log\LoggerInterface: '@logger.channel.user'

I would love to see this!
Do we have any issue where plan to add support for 'bind' in '_defaults'?
I did not find any. I only saw that in #3021898-18: Support _defaults key in service.yml files for public, tags and autowire settings → it was removed from the PR of that issue.

Here we go,
📌 Service arguments by name or type in *.services.yml with autowiring Active
📌 Support arguments binding by name or type in *.services.yml files Closed: duplicate

Deprecated some uses of logger.factory and converted them to individual logger channels, but there are a few more to go.

This needs a generic change record explaining what is happening in this issue.

What would be the equivalent logger channel service to `\Drupal::logger('file system')`?

The reason I prefer injecting the factory is performance, instantiating a channel that isn't used (and log channels are very often not used, only when something goes wrong) is fairly expensive last time I checked, Or at least the first time it happens it's expensive.

It's similar to entity storages and config objects although definitely not that expensive. We changed core to not create entity storages in __construct() and it's generally discouraged to instantiate config objects in __construct() too and store the factory instead.

If instantiation is a problem then loggers should be lightweight lazy wrappers that do the work only when something needs to be logged - but it would be good to profile this first to prove whether or not it's a problem. The idea of this issue is to improve DX to make it both easy and consistent when using different logger channels.

Can we not use service closures for this problem per https://www.drupal.org/node/3451855 → ?