Access control

Once proper authentication is implemented (**@see #16), we'll be able to design and implement data creation/modification/deletion in Hecate.
But for this to be really usable, we must be able to decide who can or can't do this, on a per object basis. By per object, I mean for each entity, item, or property ; not for all entities, items or properties.

Example of attributes:

• create a database
• delete a specific database
• update a specific database settings (look and feel, members and visibility, ...)
• create an item in a specific database
• read, update, delete a specific item in a specific database
• same as items, but for entities and properties
• update this Hecate instance settings (available views, default database settings, ...)

This list is neither complete nor definitive.

Once attributes are designed, we could deduce default "roles".
However, those roles should not drive how we design access control ; on the contrary, it's the per user attributes that must be implemented. In other terms, we must implement ABAC : https://en.wikipedia.org/wiki/Attribute-based_access_control

This issue covers design, implementation, testing and documentation of ABAC.