Adjust profile page per spec revisions
Emails tab: opt out of e-mails for specific events
Privacy tab: "public/private" instead of "lock/unlock"

Also, only show icon when private.
Add "Optional Information" form for post-registration activation

There is no server-side behavior for now. We will update this to
dynamically generate the groups dropdown (and possibly the entire form)
in a future sprint.

Refs #57
Merge pull request #172 from kdeloach/topic/optional-info-form

Add "Optional Information" form for post-registration activation
Merge pull request #156 from RickMohr/profile-page-revisions

Profile page revisions
Add skeleton group listing page
Merge pull request #179 from kdeloach/topic/group-list

Add skeleton group listing page
Profile page PR fixup
Merge pull request #180 from RickMohr/pr-fixup

Profile page PR fixup
Hide some group follows on user profile page
Fix Lint
Replace unstructured event with prototype structure
Merge pull request #185 from azavea/feature/style-events

Replace unstructured event with prototype structure
Remove lint
Merge pull request #182 from steventlamb/topic/hide_some_user_group_follows

Topic/hide some user group follows
User privacy controls

Back end:
* Separate `PrivacySettingsForm` from `ProfileSettingsForm`
* User settings page: stay on page after save or cancel (per JeffF)
* Postback to user profile updates privacy settings

Front end:
* Add bootstrap modal to show privacy settings on profile page
* Module `privacySettings.js` controls toggling and display of privacy settings
* Used in both user profile and settings pages, each with their own save and cancel buttons

Fixes #174
Include Bootstrap modal sass module

We are now using the modal for editing privacy settings on the user
profile page.
Merge pull request #187 from azavea/feature/jcw/edit-profile-privacy

User privacy controls
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.