Extract DomainPathFormHelper from DomainPathFormHooks for extensibility

Problem/Motivation

All form alteration logic was locked inside DomainPathFormHooks, which is final @internal. This prevented any reuse or customization of the form building behavior — the only option for other modules was to write a separate hook_form_alter() that duplicates or fights with the existing one.

Proposed resolution

Extract the form alteration logic from DomainPathFormHooks into a dedicated DomainPathFormHelper service (domain_path.form_helper).

Why a new service instead of using DomainPathHelper?

DomainPathHelper handles domain access checks and entity type configuration — it has no dependency on the Form API. Merging form alteration logic into it would mix two unrelated concerns and pull in EntityTypeManagerInterface, ConfigFactoryInterface, and AccountInterface dependencies that DomainPathHelper does not need. A dedicated DomainPathFormHelper keeps each service focused on a single responsibility.

Changes:

• New DomainPathFormHelper service: contains all form logic (alterEntityForm(), afterEntityFormBuild(), validateEntityForm(), submitEntityForm(), getAlterFormDomainAccess(), and related helper methods). Marked @final but not @internal.
• Simplified DomainPathFormHooks: now a thin dispatcher — checks if domain paths are enabled and delegates to DomainPathFormHelper::alterEntityForm(). Removed unused imports, StringTranslationTrait, getConfig().
• Services: registered domain_path.form_helper with FQCN alias for autowiring.
• Minor fix: replaced $path > '' with $path !== '' for clarity.
• Minor fix: removed redundant !empty($object) check in formAlter() (already guaranteed non-null by getFormObject()).

Remaining tasks

Review and test.

API changes

New domain_path.form_helper service added. No BC breaks — DomainPathFormHooks retains the same hook behavior.