Integrate with real backend

See all @backend comments in code, and all calls to connection (MongoDB). (See also @production comments that aren't really related to the backend.)

Notable changes to make:

For all search endpoints:
- Use ElasticSearch to support matching the full document with the q parameter (not just the name or description).
- Accept a location descriptor from the user, submit it to the Google Maps API to get its coordinates, and submit the coordinates to the API to do a radius search with PostGIS.
For organization detail, person detail, and search endpoints, the backend must be able to export data as text and CSVs (zipped). For the country-level files, a cron job should create them daily or hourly.
/events/:id
- organizations_nearby: Use PostGIS to determine areas and sites within a 2km radius of event.
/organizations/:id/map
- events_nearby: Use PostGIS to determine events within a 2km radius of all sites over all time.
/organizations/:id
- events_nearby: Use PostGIS to determine events within a 2km radius of all sites over all time.
/people/:id
- events: Get events related to an organization during the membership of the person.
- events_nearby: Get events near an organization during the membership of the person.
/countries/:id/search/events
- sites_nearby: May need to do a radius search for each result in PostGIS (expensive?).
/countries/:id/search/people
- events_count: Equal to the events related to an organization during the membership of the person.

The backend may want to store events_count as a calculated field to reduce the number of queries necessary to build the API response. To filter people by events_count, the current implementation requires a events_count calculated field on the Person class.

security-force-monitor / sfm-proxy

Integrate with real backend #19