xm.cms.user userrole should not be implied from other cms feature userroles like xm.content.user or xm.project.user

We currently have the xm.cms.user userrole implied, as convenience, by all the other cms feature userroles, like xm.content.user, xm.project.user, etc.

While that is convenient and thereby automatically 'grants' login to the cms when such feature userroles are assigned to a user or group, it actually is awkward and undesirable because such cms feature userroles are also implied by more domain specific userroles like xm.content.viewer!

A use-case where this is undesired is for example when the site-writer (system) user needs to be able to use document workflow. Then, the site-writer user requires also the userrole xm.content.editor, which implies xm.content.viewer and thus also xm.cms.user.
But the site-writer system user should never be intended or allowed to login to the cms (and actually won't be, because it is a system user), but it still is confusing and undesirable.

And more generally, if an external (non-system) user needs to invoke document workflow (like through a REST API) but not should be allowed to login to the cms this really becomes problematic.

This oversight however can easily be fixed and remedied by the following minor changes:

1. remove xm.cms.user from all the cms feature userroles
2. add xm.cms.user to the xm.default-user.* userroles

This  effectively amounts to the same userroles assigned to users and groups in the cms when using the default xm-default-user.* userroles, and only adds the requirement to always (also) assign the xm.cms.user explicitly for custom users/groups when not using the xm.default-user.* userroles. Which is a minor 'burden' we easily can document (and fix in a few of our demos and tests).