add drives service to store persistent list of spaces a user has access to

Currently, the `/me/drives` endpoint makes a ListStorageSpaces() call to the gateway.

That query has to return a user specific listing of spaces a user has acces to ... which is fairly expensive if not cached properly.

We will implement a new `drives` service with persistence to manages a list of drives the user has access to at the `/me/drives` endpoint.
- when you first log in an a personal space has been created for you, an explicit request adds that space to the list.
- when you receive a link to a project or share space the web ui registers the space in your /me/drives endpoint.
- you get a link to a resource, there is no difference between public or private
- the web ui is loaded
- if the user is logged in it can compare the list of spaces the user has access to (/me/drives) and add the new space with a POST request to the `/me/drives` if it is missing
- this is how the drives service learns about new share spaces: by the web ui adding it when detecting a new link in the ui (well ore via someoneelse doing a POST)
- the drives service is a dedicated service that persists the listing per user (eg as a json file on a CS3 metadata storage)
- it is a personal dictionary of spaces, which can be scaled by sharding eg. per user
- it can listen for events in the same instance
- it can poll remote spaces on behalf of clients
- it can provide a websocket endpoint to push changes to desktop clients (covered by msgraph)
- it can implement if-match logic to only send a response when something changed
- it can implement a delta api to get a list of spaces that changed since the last time a client polled
- it can be run along oc10 to add the indirection step for existing owncloud or nc deployments
- it could list an existing oc10 / nc instance as a space
- we can plan this as an ADR and make it a new feature during the beta, as the endpoints don't change
- I think we will have to do it before GA for performance reasons
- it moves the dynamic space registry from reva to an ocis service and together with the `storageid$spaceid!nameid` routing reduces complexity in reva. which is a good thing IMO
- reva edge can rely on a static registry again, see https://github.com/owncloud/ocis/issues/3431