Make groups an optional layer over site permissions and language paths, like Drupal 7

Problem/Motivation

Drupal 7 l10n_community works on its own: it defines site permissions (browse translations, submit suggestions, moderate own/others' suggestions, import, export, start over packages) and language based paths (translate/languages/hu/translate). l10n_groups depends on it and only adds: the same permissions as group permissions, a language to group mapping, an OG context handler that finds the group from the translate path, and the "Localization group information" block with the join/leave/members links. Access is "permission in the current group OR site permission".

3.0.x has the dependency the other way around, and only half of the integration:

• l10n_community depends on l10n_groups, so nothing can be tried or tested without Group, group types, roles, groups and memberships.
• The only site permission is "access localization community"; every working permission exists only as a group permission, and only three of them are declared while the code also checks "browse translations", "import gettext files" and the export permission.
• L10nAccess::check() returns the group permission when the route has a group and FALSE otherwise; there is no site permission fallback.
• Translate, import, export and reset live under /group/{group}/..., so the URLs the outside world links to (translate/languages/hu/...) do not exist, and the forms and the languages controller read the language from a field on the group in eight places and build /group/<id>/ URLs in four.
• Yet the welcome page, the pick-and-go form and the statistics already branch on whether l10n_groups is enabled, and GroupInformationBlock is already the port of the D7 block, only bound to a group route parameter for its context.

Proposed resolution

Reproduce the Drupal 7 layering with current APIs, in reviewable steps:

1. Site permissions with the Drupal 7 names in l10n_community, and an access service that grants when the account has the site permission or the permission in the translation group of the current language (when l10n_groups is enabled). A route access checker uses it. Declare every group permission l10n_groups needs.
2. Language based routes for translate, import, export and reset (/translate/languages/{langcode}/...) with the four Drupal 7 tabs; controllers and forms take the language from the route. No group routes in l10n_community.
3. Flip the dependency: l10n_groups depends on l10n_community and contributes the group permissions, the language to group mapping, the access decoration, and a context provider that resolves the language of the current route to its group so the existing block works on language pages, like the D7 OG context handler. Group's own pages and tabs stay under /group/{id}, reachable from the block.
4. Tests: the ported functional tests run without groups using site roles, like the Drupal 7 tests, plus an l10n_groups test proving the decoration: a member with only the group role gets in, an outsider with the site permission gets in, an outsider with neither is denied.

No data model or migration changes; memberships and roles stay as they are.

LLM disclosure

LLM was used to find, diagnose explain and fix this issue. With human review.