Make controllers invokable for DX and maintainability

Problem/Motivation

Consider updating controllers with a single routable and consistently named method. Each controller would then represent a single route. This would helps prevent bloat in controllers, wherein dependencies and functionality are brought in but not utilized by all routes. It avoids the need to invent a new method name for each controller/route, with a common / standardized entry point. In the case where a route needs to be deprecated or moved, we can easily deprecate an entire class without worrying about side effects.

Part of the rationale for this is to make routing definitions look a little cleaner. Much like _form, which have represent something singular. Many instances of this however will be nullified by #3311365: Use PHP attributes for route discovery as they will no longer need a pointer to _controller. This will still be still useful for projects extending/reusing controllers, or creating routing entries by other means.

Proposed resolution

Update controllers to have a single routable method, via __invoke.
Deprecate existing methods.

Paired with #3311365: Use PHP attributes for route discovery, our controllers could only require this boilerplate:

#[Route('/test')]
final class TestController extends ControllerBase {
  public function __invoke(): Response|array {
    return ['#plain_text' => 'Hello world!'];
  }

Remaining tasks

Decide if we want to do this.

Many LOCs will be affected. Subsystem maintainer approval?

Depending on the size of task, it may make sense to break into subsystems.

Decide to do controllers with single methods AND controllers with multiple methods all in one go. Or, break into two: single first, then multiple. Perhaps dependent on quantity instances (TBD)

Most instances are for tests. Some of which have controllers with quite a lot of methods. Porting these will introduce a lot of extra files and boilerplate. Should we port these also?

In the case of controllers with multiple routeable methods, common functionality needs to be identified to be converted to traits, or other, on a case-by-case basis.

Implement.

User interface changes

Nil.

API changes

Many methods deprecated, immediately replaced with a consistently named method. Or moved to a different class entirly

Data model changes

Nil

Release notes snippet

TBD

Analysis

Analysis of controller/method, sorted by method count

Non test modules

Test modules