Use a helper to build context for management views instead of a context processor

[rebeccacremona]

Hi @teovin! Thanks again for tackling the big mess of our user management templates in harvard-lil#3763.

As mentioned, I really liked the direction you took, of using named boolean flags in templates instead of intricate and repeated request.user logic. Big improvement!

In this PR, I'm proposing a slightly different architecture:

• I made views/user_management into a package, so that your UI logic could live right alongside the views that use it, instead of in independent top-level packages (or, for instance, moving it to the already-giant utils.py file)

• I moved the UI-flag-building logic into a helper function inside that module, so that views that need it can invoke it directly, instead of calling that logic inside a context processor (which is automatically called on -every- request the Django application processes)... and then, I bundled that into an optional helper render_user_management. I think this will be easier to reason about, and will save the overhead on the rest of the app's views.

• I shortened up some of the flag names, using the conventions:
  show_* — visibility (layout, filters, stats)
  can_* — actions and links
  Example: instead of can_show_user_management_title → show_full_manage_title

• I added a few more tests.

So, even though the diff is big... it's not as many changes as it looks like :-)

When you're back, let's chat about whether you like these ideas, or whether I messed up something about your original structure!

Cheers,