EZP-23266: As a developer I would like to get User[Group]s when searching/loading content

This is a second attempt to decouple Repository, repo_structure branch diff became to big, this takes a step at a time starting with:  [_As a developer I would like to get User[Group]s when searching/loading content_](https://jira.ez.no/browse/EZP-23266)

## Notes
Repository will end up with a ton of dependencies, suggestions on how to better handle that is welcomed.

To be able to de couple Repository for future needs, and to be able to introduce CustomDomainTypes we:
 1 introduce a Repository\Helpers layer where we move several existing Repo helpers.

This layer has 1 rule: It can not use Repository and it's services themselves as these are used there and that would create cyclic dependency. So existing helpers needs quite some refactoring for this, and some cleanup where done as well on dead code.

Additionally primarily for future decoupling we introduce 2 new helpers as well as will be needed to introduce Helper\PermissionService, needed to avoid injecting Repo into Repo Services, which again is needed to be able to inject Services instead of creating them inline in Repo:

 2 LimitationService and RoleDomainMapper both to not have to depends on RoleService

With (Content)DomainMapper now not relying on service we can now reuse it in UserService, however as User service depends on ContentService it would be much more efficient if the build was done in one stage, to do this we introduce:

 3 Custom DomainTypeMapper used by (Content)DomainMapper so calls to ContentService directly returns User(Group) with no further work #win:dx+cleanup

This allows a lot of cleanup and removal of code in UserService, so also win for maintainability.


## Likely followups:
- Helper\PermissionService: hasAccess, canUser, [get|set]CurrentUser and PermissionCriterion handling
- Refactor Services to use Helper\PermissionService and Transaction handler instead of Repository
       (some services have a lot of dependancies on other services, so they might need further de-coupling here to be able to undo all cyclic dependancies)
- Change to inject services in Repository::__construct(), define service definitions and remove service factory (not needed anymore after this) #win:dx+inject-ability
- At this stage consider layering permissions in own layer (like SignalSlot) so we can introduce API cache between Permission and BusinessLogic layer #win:performance
User can use multiple Locations for permissions inheritance, it will first inherit horizontally through all of its Locations and then vertically, uptree from all ancestor UserGroups. Single UserGroup can also be used for permissions in multiple Locations, but it does not inherit permissions from parent UserGroups, it only shares its permissions for Users in the subtrees.

SingleLocation UserGroups would change this. But I see you point with domain mapping for its implementation.