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.
add sqlreporting
Merge pull request #959 from dimagi/sqlreport

SQL Reporting
Merge pull request #937 from dimagi/group-types

add hierarchical reporting groups using existing group metadata
fix problem where blank translations overwrite real ones; replace blank with nbsp
Prevent issues with name length on registration

Truncate the first/last name fields when syncing from couchdb to
Django and prevent the reverse sync clearing the correct versin of a
persons name.
fix problem in trans template tag (which is also used in creating the files) where non-existent and empty string were treated the same
Use couch instead of Django for a users name

Switch to using the (non truncated) version of a users name from the
couchdb store instead of the Django copy.
move nbsp to commcare_translations.dumps
Merge pull request #966 from dimagi/trans-fix

Trans fix
Refactor user's name string in header
fix case list ui jumpiness
Merge pull request #967 from dimagi/jumpy-case-list

fix case list ui jumpiness
Add translation blocks for registration confirmation pages
Add translation block in registration success
add little module of user/case utils
Merge pull request #968 from dimagi/user-utils

add little module of user/case utils
Add tests for user sync changes
don't swallow an unexpected error while building
Merge pull request #969 from dimagi/fail-fast-build

don't swallow an unexpected error while building