In-policy roles & rules supporting complex use-cases

### Problem description
In the course of #2844 Guardian user roles and permission model has undergone a significant revamp. This tickeet addressed management of user permissions/capabilities when it comes to accessing policies. However, within the policies user permissions and roles are determined by the policies themselves. Current in-policy roles&rules definition capabilities have been found to be **not** sufficient for some of the identified use-cases. This ticket serves as a placeholder to collect such use-cases (in the "Requirements" section below), to inform the developers so appropriate enhancements to roles&rules functionality can be made.

### Requirements
Enhance the in-policy roles&rules functionality such that the following use-cases become possible:

1. Setting a limit on the number of users that can fulfil a specific role in the policy. For example, if a policy has the roles of PROJECT_DEVELOPER, VERIFIER and OWNER, we'd like to be able to say that only two people (accounts) at most can "sign up" for the VERIFIER role and only one person (account) can "sign up" for the PROJECT_DEVELOPER role.
2. Manage permissions on the level of accounts+roles, not just roles. For example, consider a scenario where a project developer wants to have their project audited by two independent auditors. Both auditors, although fulfilling the same role in the policy (e.g., "AUDITOR"), should go through the entire "audit" workflow in parallel. Instead of the policy state for the AUDITOR workflow being determined on the level of the role, the policy state for the AUDITOR role should instead be determined on the level of the accounts (users) who fulfil that role, i.e., a policy role state for each user.

### Definition of done

- The functionality is enhanced to address the requirements above
- Documentation is updated accordingly
- The corresponding API endpoints exist and documented

### Acceptance criteria
Users are able to configure their in-policy user roles and rules of their authorisation and activity such that any (and all) of the use-cases in the Requirements section are covered.