Refactor the usage and exposure of the SecurityService

The SecurityService introduced with REPO-628 and exposed through the HippoWorkspace uses the current user session for loading User and Group info from the repository.

For the security domains, this implies (requires) users to have read access to the users and groups storage in the repository, which is undesired.

To 'break' this problem, the SecurityService will be refactored to be only available through the HippoServiceRegistry and use an internal systemSession instead. Which means all method access to the SecurityService must (become) thread safe, e.g. synchronized.

In addition, the current User and Group interfaces expose iterable getters for looking up memberships between them.
And the User object is also exposed on the HippoSession.
For this we will change these methods (backwards-incompatibly) to only return a Set<String> of the ids of the memberships.
Which then (still) can be looked up through the getUser(userId) and getGroup(groupId) methods of the SecurityService.

Finally, the HippoSession.getUser() will be refactored to return a pre-loaded instance stored immutably in the session Subject at login.