Align and correct the logic whether a CMS user is a webmaster and/or can manage changes / delete a channel

Currently the HST uses a quite quirky lookup whether a cms user is

• A webmaster, aka can change HST configuration
• A channel admin, aka, can manage others' changes (and sometime delete channel)

The webmaster check is done by checking jcr readwrite against the HST configuration root path, for example /hst:myproject or /hst:hst.

The 'channel admin' check is done by checking whether the user has on the HST configuration root path the privilege configured at

/hippo:configuration/hippo:frontend/cms/hippo-channel-manager/channel-manager-perspective/templatecomposer/@manage.changes.privileges

By default this privilege is hippo:admin.

There are multiple problems with the current setup :

1. The HST code needs to lookup the property @manage.changes.privileges at a path completely outside the context of the HST (even bootstrapped by a downstream project)
2. It is impossible to make a user webmaster on channel A and B, but not in channel C. Same goes for hippo:admin. This is because the check is done against /hst:myproject or /hst:hst and cannot be done against a more finegrained path

Apart from the above, the HST SecurityModel also has to map the '@manage.changes.privileges' to some RolesAllowed logic to make sure certain rest endpoints are only allowed if a user has the right role. However it is clearly mixing privileges / permissions with RolesAllowed.

We can better come up with a custom annotion, @PrivilegeAllowed , @PrivilegeRequired of @PermissionRequired and a new interceptor checking against one of these annotations instead of 'isUserInRole'