Enhancements and fixes to Groups endpoints

[Etsija]

As the Groups endpoints added in PR #753 are, there are several open questions in the way we work with them:

1. The groups are mutually exclusive: READERS can read items -> WRITERS can read and edit the items -> ADMINS can read, edit and delete items. As they are, there should be no reason why a user should belong to several of these groups for the same item (org, prod, repo). However, the endpoints do not enforce this exclusivity, so the admin can put a user for example as a reader and an admin for a repository, which doesn't make sense, really, and it has been seen to also create some mystical CORS failures in the UI.

2. There should be some sort of cascading from bottom-up in these access groups. Example: an admin puts a user as an admin for a repository, but forgets to put him as a reader for the corresponding organization to which this repository belongs. The consequence is, the user cannot see this repository at all in the UI, as he cannot see the "path leading to the repository", ie. org -> prod -> repo. Moreover, he cannot access the repository even if he knows the path, because the UI blocks him from accessing the breadcrumb in the header showing the path to the repository.

As a minimal fix for this, the back-end should probably check that when a certain group right is given for a user, the user also belongs to groups hierarchically up the inheritance tree.

Example: when a user is given admin rights for a repository, it needs to be checked that he also belongs to at least READERS of the organization and product to which this repository belongs - and if not, add the READERS rights to those items for the user.

3. Related to item 2, the group rights are probably too wide at the moment: when a user is given READERS rights to an organization, he automatically sees all products belonging to this organization, and this cascades top-down. At some point we probably want to restrict this so that the users can only see items to which they have some group rights.

4. There seems to be a problem with the auth header when "too many" groups rights are given to a user, see Access token becomes too long when too many roles added to a user #1058.

Related issues: #1031, #1055.