Name resolution and Storage refactor

### Search

The initial version of the search API is now working, you can query for a name and it will return all the records which match that name.

I've initially gone with the double metaphone implementation because it was already done in popit, although that implementation wasn't working because writes go via the API (so the code that does the name indexing wasn't being called in popit), so this pull request actually fixes the popit implementation of search as well (by accident). I didn't use mongo's search implementation because it's still marked as experimental, it's not even enabled by default you have to give a special flag when starting the daemon.

However I'm not totally happy with this solution. The search queries are slow, 500ms+ on my laptop with a relatively small data-set, which I believe is because the double metaphone search is querying mongo with regular expressions. This approach also litters the document with an `_internal` field where it stores the double metaphone information.

It seems that perhaps elasticsearch would be a better approach, it's designed for search after all, and it would mean that mongo can focus on popolo data storage.

### Storage refactor

I've also taken the opportunity to do a pretty major refactor of the storage implementation. The `Storage` class is now gone and it's duties have been taken over by mongoose. There are several reasons for using mongoose as the ORM layer rather than using mongo directly:

- When updating document, partial updates can be performed, so you can PUT just a name attribute without replacing the whole document.
- Validations can be performed outside of the request/response cycle. This isn't currently implemented fully, but validations can now in theory be done at the model level, rather than at the request level (which we're doing currently with the `validateBody` middleware).
- Easier hooks for manipulating JSON output. There is now a central place for swapping _id and id fields, removing hidden fields etc.
- When reading documents, the full JSON representation will be returned, including any fields which haven't been filled in yet, giving a clear indication of the range of allowed fields.

This will require a bit of work in the main popit repo to change how it handles memberships, but other than that it's all working well.

Fixes https://github.com/mysociety/popit/issues/267