Feature/risk assessment

I understand, but:

It's entirely acceptable for extensions to change the permissions applied to core objects -- the entire permission structure is specified in an extension, after all (though it's so deeply integrated -- especially client-side -- that `ggrc_basic_permissions` might as well be considered core).  Extensions definitely have the potential to introduce security issues, that's unavoidable, but it's something to be evaluated per-deployment when deciding which extensions to enable.  (Hopefully with shortcuts of known-good combinations at some point.)

The current permission framework specifies purely additive roles -- e.g., adding a role or a new permission specification can never reduce access.  In this light, it might make more sense for each extension to specify the full set of permissions that it depends on for proper operation.  E.g., since Risk Assessment functionality depends on Program-context permission to Document and ObjectDocument, both should be specified in `ggrc_risk_assessments`, even though it may overlap with permissions granted by core (or other extensions).

It's also a code-level separation of concerns issue.  If the core module doesn't depend on access to Document, it shouldn't require it.  (This doesn't really translate, currently, because, e.g., core doesn't require any of the `GGRC.register_hook` functionality, but provides it.  Eventually, "core" should consist entirely of wiring, and content should all be introduced via hooks/extension mechanisms.)  In the future, when extensions are in separate repositories, developers on extensions shouldn't need to worry about permission removal breaking other extensions -- they should just specify the set required for operation of their isolated extension.