Issue #3615915: Provide entity routes through EntityRouteProviderInterface

The domain and domain_alias entity types now declare an AdminHtmlRouteProvider route provider handler, so their form routes are derived from the link templates instead of being repeated in the two .routing.yml files.

Routes now generated

Route	Entity type
entity.domain.add_form	domain
entity.domain.edit_form	domain
entity.domain.delete_form	domain
entity.domain_alias.edit_form	domain_alias
entity.domain_alias.delete_form	domain_alias

The paths, the _entity_access and _entity_create_access requirements and the _admin_route option of the domain record forms are unchanged.

Route name change

Core names the add form route after the add-form link relation, so entity.domain.add becomes entity.domain.add_form. The old name is kept as a route alias, following the precedent already used for entity.domain.collection in [#3613844], so Url::fromRoute('entity.domain.add') keeps working for third party code. The entity type declares an add-form link template for the path the route used to hold.

Behavior changes

• The form page titles now come from the title callbacks core attaches, so the domain record forms read "Edit <name>" and "Delete <name>" rather than "Edit domain record" and "Delete", and the alias forms likewise. Local task titles are unaffected, since they come from domain.links.task.yml.
• The domain alias forms gain the _admin_route option that the domain record forms already had. They are reached from the domain record edit form, so they now use the administration theme like the rest of that flow.
• The add form runs the default form operation rather than edit, because the entity type declares no dedicated add form handler. It is the same DomainForm class; only the form ID changes, from domain_edit_form to domain_form. Nothing in the project keys on either ID.

The listing route is deliberately left alone

domain.admin stays in domain.routing.yml and keeps entity.domain.collection as its alias, for two reasons:

1. DefaultHtmlRouteProvider::getCollectionRoute() can only express the entity type's admin and collection permissions, and the listing grants access to a third one: administer domains+view domain list+view assigned domains.
2. Local tasks, local actions and hook_help() are keyed by the name of the route that serves the page, and an alias is never path matched. Letting the provider own the listing would rename the serving route and silently detach the tabs that domain_path, domain_entity, domain_menu_access, domain_theme_switch, domain_site_settings and domain_group attach with base_route: domain.admin.

The same reasoning keeps domain_alias.admin and domain_alias.add in place: the alias listing and the alias add form are built per domain record by a controller, so neither is a route a provider could generate.

Tests

DomainEntityRouteProviderTest and DomainAliasEntityRouteProviderTest assert the generated paths, form operations, access requirements and _admin_route option, the add form route alias, and that the alias is not path matched. They also pin the listing permissions that kept the listing route out of the provider.

Note for the committer

This touches the #[ConfigEntityType] attribute on Domain.php, so it will need a rebase against [#3615914] whichever of the two lands second.