CLC-4070 CLC-4100 Centralize CalCentral authorization

https://jira.ets.berkeley.edu/jira/browse/CLC-4070
https://jira.ets.berkeley.edu/jira/browse/CLC-4100

This attempts to unify our current authorization checks in a way that will be fairly easy to build on, abstracting low-level user-record details into a controller-and-Pundit-friendly spot.

There are still a number of places where authorization checks happen below controller code, and so the "current_user" object can also be embedded in models. Much more dangerously, it can be mimicked by them (Canvas::CourseProvision is an example). I hope we can discourage that, though.
Understood, @ctweney , and I started it there. I bumped it to the top is because I expect other CalCentral Pundit policies to subclass it (as seems to be recommended best practice). To put it another way, this is not exactly a "Policy on an object (called '@record', by convention) which represents a user." This is the *default* policy which takes effect no matter what else is going on, and it deals solely with the "current_user" context object which is passed to all Pundit policies as the first argument of the initializer (called "@user", by convention).

So for example a Berkeley::CoursePolicy class would receive the same sort of "current_user" context object as the first argument in its initializer, and the second argument ("@record") has the course that the current_user will be authorized against. But anything which is referring to that Berkeley::CoursePolicy will be able to use the same policy object to check for (say) "can_administrate?".

Since AuthenticationState applies to pretty much every controller, no matter what models it uses, it feels iffy for me to associate it specifically with the "User" module.

That said, if you still disagree after suffering through all this, I'll be glad to move it!