Authorization system

[artem-v-shamsutdinov]

A repository level authorization system is needed.

[Note, there is no need for user facing App authorization since all Apps are sandboxed and cannot transfer data outside of their sandbox (except to and from AIRport). Once advertisement revenue is distributed between apps there may be a need for one but it really also makes (perhaps even more sense) to let the best App/UI win (which is also mitigated by the fact that Apps should get the bulk of the revenue, vs UIs) and that they control persistence to their schemas and the business logic around that.]

Since initial integration will be with files.chainsafe.io initial roles are limited to:

• Owner
• Can-write
• Can-read

Permissions are always maintained by the owner.

Thus, this defines the scope of the original implementation. This should be tracked in Repository to ensure no-vendor lock-in - Repository authorization should be portable off Files API. This is necessary especially for the case of Repository being ported to permanent storage (like ArWeave or Lighthouse).

In the future expanded features can be:

1. The initial user is by default the administrator user for a Repository.
2. Admin users have read and write permissions.
3. Admin users can add and remove read and write permissions to any non-admin user of the repository.
4. Initial user is the super admin and can grand and remove Admin status.
5. AIRport enforces all of the above rules.