Provide entity routes through EntityRouteProviderInterface

Problem/Motivation

Drupal entities typically provide their routes through a route_provider handler. These route_provider classes provider boilerplate routing, so these can be removed from .routing.yml files

Steps to reproduce

See for example https://git.drupalcode.org/project/domain/-/blob/4.x/domain/domain.routi... and https://git.drupalcode.org/project/drupal/-/blob/main/core/lib/Drupal/Co...

Proposed resolution

Provide entity routes through EntityRouteProviderInterface

Remaining tasks

1. Write a merge request
2. Review
3. Commit

User interface changes

The edit and delete pages are titled Edit %label and Delete %label, because their titles now come from EntityController::editTitle() and deleteTitle() instead of the static ones the routing files carried. Tab titles are unchanged, since those come from the local task definitions. The domain alias edit and delete routes gain _admin_route, which domain's already had, so those two pages use the admin theme and load the parent domain without configuration overrides.

API changes

This is a backwards-compatibility break. Two of the three items below fail silently, so they are worth a change record and a release note.

• DomainAliasController::addAlias() is REMOVED. The controller class survives with listing() and listingTitle(). Its prepopulation of the parent domain moves to DomainAliasForm::getEntityFromRouteMatch(), which is the seam core calls. Anything calling that method, or pointing a route of its own at it, breaks outright.
• The add form's form ID changes from domain_edit_form to domain_form. The entity type declares no add form handler, so the generated add route runs the default operation where the old route named domain.edit explicitly. An implementation of hook_form_domain_edit_form_alter() written to catch the add form silently stops firing on it. An alter written against hook_form_domain_form_alter() is unaffected, because that is the base form ID hook and it already fires for both operations. The domain alias add form keeps the ID domain_alias_form it already had, since the removed controller also ran the default operation.
• Five form routes move out of the routing files and are generated from the link templates: entity.domain.add_form, entity.domain.edit_form, entity.domain.delete_form, entity.domain_alias.edit_form and entity.domain_alias.delete_form. The names core derives match the names those routes already had, and the two historical names survive as aliases, entity.domain.add of entity.domain.add_form and domain_alias.add of entity.domain_alias.add_form, so Url::fromRoute() keeps working for both. Both entity types now declare a route_provider handler, and domain_alias declares a DomainAliasHtmlRouteProvider that keeps the add route's own access requirements rather than core's _entity_create_access.

No contributed project that integrates with Domain was found to reference DomainAliasController::addAlias(), to alter domain_edit_form, or to name entity.domain.add or domain_alias.add, so the exposed cases are custom code and any project not checked here.

Data model changes

None

AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)