Define and document a clear policy to name commands in the command line interface

We are trying to converge towards debusine <concept> <action> but that level of specification is not sufficient for developers to make consistent choices:

• we don't know when a concept is worth a top-level keyword
  • ex: debusine workspace-inheritance exists but not debusine-admin roles or debusine-admin file_store (though workspace inheritance is certainly more closely tied to workspaces than roles)
• we are not clear how to handle sub-concepts involving multiple sub-actions
  • ex: we have debusine-admin scope add_file_store|edit_file_store|remove_file_store but we also have debusine-admin group members --add|--remove|--set or debusine workspace-inheritance --edit|--append|...
• some actions are implicit, some are explicit
  • ex: listing roles is debusine workspace list_roles …, but listing members is debusine-admin group members $group