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.
@jwalgran I think that's a cool idea, but it might be masking the fact that the `group_request` decorator should actually be applied using the `@` syntax within the view file, if it is a direct dependency of the function that's using it. If it was idempotent, it would essentially be syntactically and performantly equivalent to adding `raise_404_if_missing(request.group)` to the body, with the added benefit that it can be safely mixed in to decorators upstream as well.