Introducing a new RepositorySecurityManager for a HippoSession (via HippoWorkspace)

To further simplify the security domain management and support and strengthen the separation of security management responsibilities, a new RepositorySecurityManager service is added which is bound to a HippoSession, accessible through its HippoWorkspace (just like the WorkflowManager).
This new HippoWorkspace.getSecurityManager() service provides specific security management features which access is restricted through the logged in user its user roles, e.g. like the new xm-security-manager, xm-security-user-manager and xm-security-application-manager userroles (see CMS-12252).

This will also be used for CMS-12065 to adjust and update the Admin panel plugins in the CMS and other security related features like verifying and updating the current user password.

Furthermore, readonly access to UserRole and Role data will be provided through a new UserRolesProvider and RolesProvider, and a new UserRolesManager will be provided to support implementing a new CMS Admin plugin for managing (create/update/delete) custom userroles.
And because its features and capabilities are just really the same, also a RolesManager will be introduced (although it is not planned, for now, to implement a corresponding CMS Admin plugin).

Because we currently already have a org.onehippo.repository.security.SecurityService, as well as an (internal) org.hippoecm.repository.security.SecurityManager, the new RepositorySecurityManager and related providers/managers, and their related interfaces (REPO-2243) will be moved to a new com.bloomreach.xm.repository.security package to prevent naming clashes and (further) confusion.

Finally, to improve its practical usage HippoSession will override the return type of the standard JCR getWorkspace() method by returning a HippoWorkspace. It no longer will be needed to cast to HippoWorkspace anymore!
(a similar improvement will be done through CMS-12065: the UserSession and PluginUserSession getJcrSession() method will return a HippoSession instead of plain Session)

The UserRolesProvider and RolesProvider are both using their own back-end model which is kept automatically up-to-date (in the background) using an synchronous session listener. These security providers (more to come) thus can and are shared between all HippoSessions because they are fully thread-safe.

The security managers (for now UserRolesManager and RolesManager, more to come) all share a dedicated system session per HippoSession for performing the actual JCR data changes. They only use their bound HippoSession for access checks and for example audit trailing.