Serve every entity relation through one relation service

Each relation (project - resource group, domain - resource group, project - container registry) is served by its own domain code, though the relation ops (`RelationOpsProvider` / `V2RelationWriteOps`) and the relation specs (BEP-1075) already answer all of them the same way.

### Work
- One relation service takes the pair `(scope, target)` and the relation kind, and runs create / delete / restore / purge through `RelationOpsProvider`.
- A registry in `models/specs` maps each relation kind to its creator, lifecycle updater and purger; the sweep in `tests/unit/manager/actions/test_registry_catalog.py` covers it.
- Replace the per-domain code with calls into the service: the resource group's allow / disallow commands over `sgroups_for_groups` and `sgroups_for_domains`, and the container registry's `allowed_groups` update over `association_container_registries_groups`.
- Relation tables carry foreign keys with cascade on both sides, as `association_container_registries_groups` does after BA-7593.

### Notes
- After BA-7593. Sibling of the domain - container registry relation.

JIRA Issue: BA-7657

Start by reading RelationOpsProvider and V2RelationWriteOps, then inspect the relation registry in models/specs and the sweep in tests/unit/manager/actions/test_registry_catalog.py. Trace the resource-group commands over sgroups_for_groups and sgroups_for_domains, and the container-registry update over association_container_registries_groups. Done means these relations use one service for create, delete, restore, and purge, with the documented foreign-key cascades preserved.

Written by the indexing model from the issue text.