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.

<!---
@huboard:{"order":1346.7445068359375,"milestone_order":1300,"custom_state":""}
-->

This test doesn't seem to me to test anything important about the `search` method. It just tests the happy path. I'd guess that part of the reason why is because so much boilerplate is needed just to set up the test, including mocking `Annotation`, `get_user`, providing a request and a context, etc, etc.

I'd rather see the central logic of `search` extracted into a function that knows nothing about the request, and nothing about the context, something like:

```python
def _search_params(query, offset=None, limit=None, userid=None)
    if offset is None:
        offset = 0
    if limit is None:
        limit = 10
    limit = min(limit, 100)
    offset = max(offset, 0)
    params['limit'] = limit
    params['offset'] = offset
    if user is not None:
        params['user'] = user
    return params
```

You can then test this method independently:

```
class TestSearchParams(unittest.TestCase):

    def setUp(self):
        # patch h.api.Annotation

    def test_search_defaults(self):
        ...

     def test_search_min_offset(self):
        ...

    def test_search_max_limit(self):
        ...

    def test_search_with_user(self):
        ...
```
and provide the API view function as a thin wrapper over the core logic of the search_params function. At that point, you probably don't even need to write tests for the API view function.

Some of the above may not be relevant in this case, but in general I feel like the edge cases aren't actually being tested, and overall the test is very tightly coupled to the particular implementation of the API view method.