Refactor API code to use annotator-store flaskless

Everything seems to work: reading, creating, updating, deleting, searching, permissions seem to work but need better testing, and in general more tests and thorough code review would be good.

To keep a consistent style and make refactoring easier, I decided to use traversal with a `@view_defaults` class everywhere, using the defaults class to specify the `context` predicate, so as to group the views within that. For the same reasons I do not use view names but use a resource for each location (I explictly state `name=''` for clarity, though that could be removed). I think this style works out nicely.

I put some questions in the comments, just search for the question marks.

The dependency on the next (flaskless) annotator-store version has yet to be added.
Is this style of class naming common? It looks ugly to me… I've always liked the PEP8 style of just using pure camel case. http://legacy.python.org/dev/peps/pep-0008/#class-names