Make sure memberships are populated in the API

This is quite a crude initial implementation, but it does achieve the
desired outcome of populating the memberships array.

One worry about this is that it might give people the impression that
you can create memberships by POSTing them as part of the person, but I
guess thorough documentation can get around issues like this.
Move json transform into a plugin

This means that all of the add-on functionality for the core popolo
models exists in plugins, which hopefully makes the actual model
definitions a bit clearer.

I think further improvements can be made to the clarity of the model
definitions by merging the collections.js module into models.js. That
way there is one central place which defines the popolo models for the
application.
Enable mongoose debug if MONGOOSE_DEBUG is set

If MONGOOSE_DEBUG is set in the process' environment then we enable
mongoose's debug flag, which logs the queries being performed to STDOUT,
which can be very useful when debugging performance issues etc.
Fix tests that depended on the exact API output

Rather than asserting the whole body of the API response matches our
expectations we instead just check subsets of the body to see if
elements are visible/hidden appropriately.
Delete memberships from json docs before indexing

Due to memberships being stored in a different collection, we can't index
them in elasticsearch as embedded documents because they may change in
the database but the related record wouldn't be reindexed, so they would
fall out of sync.

In the future it might be worth making the list of fields to exclude
from the json configurable on a per-model basis, so the person model
could be configured to always hide memberships. This could possibly even
be inferred from the JSON schemas somehow.
Merge branch 'memberships-in-api-output'