Deprecate magic ServiceProvider file discovery

Problem/Motivation

Currently service provider for a module called the_module_name must be in a class called Drupal\module\TheModuleName. This naming is rather brittle, very hard to learn (and the decision to do this was made outside of normal core processes).

Steps to reproduce

Proposed resolution

Before going into the proposals, let's note YamlFileLoader has been forked from Symfony because at the time adding the Config component was not desirable however in #2464053: Remove @todo to Improve YamlFileLoader so that we can cache built service definition objects and not just the raw data. Drupal specific file caching was added which makes it fairly impossible to unfork it ever again. Thus, I will not list editing YamlFileLoader as a con.

Several proposals exist:

1. Add a service_providers key in services.yml. Pros: multiple classes can be registered with ease with any name. Cons: it's a new Drupalism in services.yml.
2. Call the class Drupal\module\Services or ServiceProvider. Pros: it's very simple, avoids weird naming for more complex module names. Cons: it's still magic naming -- however checking for the all lower case version as well is not too hard to avoid FS problem.
3. Put the registration in the module info yml (or composer.json). Pros: it keeps the Drupalisms in one place. Cons: alexpott doesn't think it belongs there.
4. ✅ Make them tagged services. Pros: it's easy and cheap to implement both in core and in modules. Cons: not much? injecting services need to be done with care because the container is still being built but then again both methods of these classes already receive the container and need to be careful with getting services so nothing new is happening here, really.

Remaining tasks

Choose approach 4 has the most votes for now
Review https://git.drupalcode.org/project/drupal/-/merge_requests/11198/diffs
Decide whether ServiceProvider classes should be renamed (as is in the current MR) or keep the ServiceProvider suffix.

User interface changes

N/A

Introduced terminology

N/A

API changes

Service providers are now tagged services

Data model changes

N/A

Release notes snippet

N/A

Original issue summary

In the docs at https://www.drupal.org/docs/8/api/services-and-dependency-injection/alte...

> Note that if you want this service alteration to be recognized automatically, the name of this class is required to be a CamelCase version of your module's machine name followed by ServiceProvider, it is required to be in your module's top-level namespace Drupal\your_module_name, and it must implement \Drupal\Core\DependencyInjection\ServiceModifierInterface (which ServiceProviderBase does).

The relevant code is in discoverServiceProviders().

It seems a bit backwards to be doing magic discovery on a class name, when all other things of this sort are done by explicitly declaring the class -- eg dynamic routes, dynamic permissions.

In line with that pattern, we should declare a dynamic service provider in the module's services.yml file.