Implement role and permission checks at the API Level (Phase 3)

We have authentication/authorization tokens (e.g., JWT) in place for every API request. Only authenticated users (those with a valid token) can access APIs. We also have in place a matrix of "allowable actions" that restrict users from actions (filings) they are not allowed to do. However, these do not stop a user with a valid token from filing an allowed filing with invalid content -- ie, content that our UIs will prevent, but that could be put/posted to the API directly (using Postman or an alternate UI). For example, there are a number of amalgamation overrides that only staff can normally do, but which could be spoofed in a direct put/post to the Legal API.

This epic is for implementation of the next layer of protection - permission checks for content posted to an allowed API endpoint.

Acceptance Criteria:

- Enforce fine-grained permissions in the API level.
- Log all sensitive actions to help detect and investigate unauthorized behavior.

More info:
- see allowable actions (which the API uses to prevent filings that aren't allowed/authorized)
- see permissions (which the UI uses to show/hide or enable/disable actions according to account's role)
- https://docs.google.com/spreadsheets/d/13P4ZA19lJfXJX95N5OfQMu6jYuotDH6h2hDf2DnAv0E/edit?pli=1&gid=1335805235#gid=1335805235
- there is some overlap between allowable actions and permissions

Three types of permission checks are possible:
1. by filing (ticket #27211)
2. by filing content/JSON (ticket #29528)
3. by non-filing endpoint (ticket #29967)