[WIP] Sticky privacy on the browser

Following @aron's idea I open this PR to get the best of both #1714 and #1716 

It does the following:
- The permission plugin no longer sets the permissions
- Because of this the read permission can be a one-item list for public annotations too: `["group:__world__"]` instead of `["group:__world__", <username>"`
- Privacy directive moved from `directives.coffee` to `directives/privacy.coffee`
- It uses the simple localStorage solution instead of angular-cache but not as a service, but as just some private functions for the privacy directive.

What is not nice:
- I've kept the visibility constants from the my branch but actually it looks rather stupid to store them in the localStorage and convert them to the appropriate privacy levels string
- I do not know how to get rid of the `privacy-default` variable. The directive does know nothing about the annotation and it is the only way to feed it with annotation data
- When we create a reply we have manually adjust its permissions, because there is no way inside the directive to read the parents permissions. Maybe, we could do this by including the annotator service inside the directive and use annotator.threading.getContainer .. something.. but that is overkill.

Questions:
- Was there any other reason to have the user in the `permissions.read` besides the permissions plugin?
- How can I reach the logged in user from the privacy directive? (Currently I'm just simply using annotation.user)

So thoughts are welcome. This is WIP, anything can change.
I think it's better to use `.setItem()` in general. Using property names does work. Property names like `setItem` would of, of course, conflict with the methods. While we're not likely to have that problem, I think it's probably just a safer practice to consistently use `getItem()` and `setItem()`.