Mint scope-based access tokens for RBAC

[ishank011]

Primarily, this PR is meant to introduce the concept of scopes into our tokens. At the moment, it addresses those cases where we impersonate other users without allowing the full scope of what the actual user has access to.

Going by owncloud/ocis#1971, it serves a similar purpose. We can modify the current design to incorporate both the things. I wanted to finish coding it so that I could verify its correctness.

Here's a diagram detailing how the tokens are minted and additional scopes added https://codimd.web.cern.ch/XTib-1TzTyqx2IZJJOq5pA (you might have to zoom in a bit). Also a short explanation:

• We get the public share using the token provided by the client.
• In the public share, we know the resource ID, so we can add this to the allowed scope, but not the path.
• However, later OCDav tries to access by path as well. Now this is not allowed at the moment. However, from the allowed scope, we have the resource ID and we're allowed to stat that. We stat the resource ID, get the path and if the path matches the one passed by OCDav, we add it to the scope as well.

Serves as a better approach to #1549, closes #1549.

Depends on cs3org/cs3apis#123

[ishank011]

One caveat is that whenever we try to access a resource by an attribute that is not added to the token scope, we'll have to resolve it (resource ID -> path or vice versa). Even if we append the scope by adding the missing attribute, we can't pass the new token back to the caller.