Moar authorization attributes

Based on PR #2117.

Future PRs will
  - refactor the growing code duplication in `test/integration/auth_test.go`.
  - replace injected Authorizer with a new authorization mode and acl file.
  - improve documentation.
 

One concern here - now that the authorizer is part of Master, it's impossible for a consumer of Master to inject an authorizer wrapper that mutates or alters the behavior of the core authorization.  So anyone attempting to load Master but alter authorization behavior (i.e. the mode, or the new from file location) is out of luck.  I'd prefer that the master have the authorizer passed on config, and that authorizer construction happen before you initialize the master.  If that conflicts with anything I said before, I apologize.

Some concrete examples - we'd like to do the following things, probably in the same space of time that the work here is evolving:

* Load the policy from etcd
* Disable the policy altogether
* Generate an admin user on the fly on first startup and if not set, assign a policy to them automatically
* Wrap the policy logic to contextualize from namespace (project).

Having the authorizer initialized inside master.New essentially blocks any of that, which makes it harder to prototype or test aspects of authorizer functionality.