Expand Iroha Permission model

Author: Iurii Vinogradov

Incomplete model of the roles and rights of Iroha is one of the key reasons for the need to create a layer of services around the blockchain core.
Having a full-fledged rights model in Iroha will greatly reduce the amount of server development for Iroha-based applications.

1. Iroha has permission can_get_my_account_detail for an account.

   Proposal: It is proposed to give the opportunity to issue the permission to view single account details to all users of the domain/network (for example can_get_my_account_detail_for_domain, can_get_my_account_detail_for_network). This concept is common in the Linux world - give permission to a group of users. In Iroha, we have two groups - domain and whole network.
   Reasoning: Iroha allows storing data only in the details of an account. This feature is often used to store business settings that all domain/network accounts should have access to. But Iroha permission system allows only to issue the right to view own details to one account. This complicates the situation and requires external private keys management & formation of callbacks for new accounts creation, to issue rights to the necessary accounts. Another possibility is to give permission to view all accounts details what is not secure. If the accounts will be able to issue rights to their data to the entire domain/network, this will solve the problem.
   
   
2. Iroha has just one type of account group type- domain.
   Proposal: Ability to create groups of accounts. Each account can be added to different groups at the same time. It will give the opportunity to use proposal #1 in a more flexible way. Another way to implement this functionality is a role to role relationships.
   Reasoning: Enterprise role and permission systems, especially in finance, are often complicated enough. And grouping users can give benefits in simplification of permission allocations. Concept of groups is different from the concept of roles, because users in a group can have different roles(like different users of Iroha domain) but share some in common(ex. rights of access to specific account details). Also, for now, it is not possible to change the domain of a user but will be possible with groups. Roles vs groups: https://stackoverflow.com/questions/7770728/group-vs-role-any-real-difference
   
   
3. For now, Iroha has no parameterized permissions. 
   Proposal: Create parameterized permissions.
   Reasoning: It will give the necessary flexibility to the permission system. For example, if super Admin wants to give Admin rights to manage permissions of other accounts. Example: can_manage_account_permissions(manager, subordinate). Sora project case - sending voting points only to project accounts - also easier to implement with parameterized permissions.
   
   
4. Hierarchical accounts.
   Proposal: Hierarchical accounts(including multisig) is a common need for Enterprise where employees manage the company funds. It is possible to implement with permission system or with hierarchical deterministic keys. 
   Reasoning: Hierarchical accounts is a common need for enterprise clients and also will simplify network regulators control which is difficult in current realization because regulator accounts have to control quorum of multisig accounts what requires a large number of extra keys.