add hierarchical reporting groups using existing group metadata

HSPH has a few user group hierarchies where they want linked user
selectors on reports that show children dependent on what parent you've
selected.

There doesn't seem to be an obvious way to do this.  There had been
group names hardcoded in containing the parents and then I hardcoded a
particular relationship between the parent username and the name of the
group that would contain all their children, but this breaks when groups
get renamed.

There was the possibility to handle this by creating a new fixture data
type for each type of user relationship and then adding fixture items
containing one user and one group each.

However, I thought I'd just implement it with groups using the existing
metadata interface.  I did this by adding semantics to these group
metadata properties:

  user_type: indicates that all of the users in this group are of a
      certain type.  This is used to identify the root users for a given
      hierarchy but can also be used to validate the types of descendant
      users in the hierarchy if there are groups for their types too.

      This is simply any string.

  owner_name: for a one-to-many relationship group, the raw_username of
      the owner
  owner_type: the user type of the owning user.
  child_type: the user type of the child users.

I've tested this with up to a 3-level tree.  It also isn't integrated
anywhere yet (I added one to HSPH but waiting on setting up groups on
prod to integrate it with the reports).

I don't see any reason this model wouldn't work permanently for
hierarchical reporting groups.  It doesn't constrain the types of
hierarchies that can be configured (for example, it allows overlapping
hierarchies), and I don't think there's going to be a much more
efficient way to query things without introducing a huge amount of
denormalization and complexity.  And it shouldn't be hard to adapt if we
want to make these metadata properties first-class citizens of the group
model.

Haven't really thought about the implications for hierarchical case
sharing, though.

If we don't want this then I can easily swap out fixtures for groups in
the algorithm to meet the immediate needs for HSPH.
revamp how locations get attached to cases and forms

- use signals instead of relying on commtrack helper functions
- only fire signals on commtrack cases
- this also adds a stub model for supply point products + tests
- and adds a fix and test for attaching locations to requisitions + forms
- should have less writes to couch for standard submission workflows too
fail gracefully in domain admin report
add search
remove real_space; default to true for is_test
new properties in ES index; modify columns in domain report
add trans; remove comments
add sqlreporting
Merge pull request #952 from dimagi/reports

Modifications to the domain admin report.
Port all REST API resources to Tastypie v0.9.14
delete no longer relevant comment
Allows mach backend to use unicode characters
Merge pull request #961 from dimagi/mach-unicode

Allows mach backend to use unicode characters
Merge pull request #947 from dimagi/commtrack-reqs

revamp how locations get attached to cases and forms
Mach backend encoding fix
Merge pull request #962 from dimagi/mach-unicode

Mach backend encoding fix
properly cast case types in helper functions and add helper + test
Merge pull request #963 from dimagi/commtrack-reqs

properly cast case types in helper functions and add helper + test
Merge pull request #960 from kennknowles/tastypie-0.9.14

Port all REST API resources to Tastypie v0.9.14
update fabfile to use ssh config and warn if using default master branch during staging deploy