Secure group edit with new decorators

This is a large refactor that allows for chainable decorators that decorate the ``request`` with a group object and enforce editability constraints base on the logged in user.

The ``group_request`` decorator takes it's cues from the auth context processor. Views wrapped with this decorator will have a ``request.group`` in addition to ``request.user``. This makes for easier composability of decorators and has the side effect of ensuring that the group is only queried once.

I renamed the existing decorators to make them more forceful. For example ``is_census_admin`` is now ``user_must_be_census_admin`` which is more suggestive of the fact that a view wrapped with this decorator will return 403 Forbidden if the ``request.user`` is not an admin.

While working on the decorators, I also clarified the two different types of training, which grant different levels of page access.
I think that's a fair concern, but a misconfigured route is always going to be a problem, regardless of this code path. Getting a quick fail instead of a subtle inaccuracy is probably better.

That said, it may be a good idea to:
1) make `group_request` idempotent, such that it looks for `request.group` before acting on it.
2) have this decorator always wrap with `group_request` because it's cheap to throw it in there for safety
3) not worry if a route does or does not wrap with `group_request`