Refactor authentication and authorization

We're trying to separate these two concerns as much as possible:
- Token decoding sets the token_info in the SecurityContext. Valid
  values are stored directly, invalid values are stored as the symbol
  :invalid_token, and missing values are stored as nil.
- Authentication happens completely in the check_authentication method of
  the base controller model (base.rb). Raises NotAuthenticated if the
  token is missing; raises InvalidAuthToken if there was an error
  decoding the token. This method is called before every controller
  action is dispatched.
- Authorization happens during the validate_access method of
  model_controller. The logic for authorization is maintained in the
  Allowy access classes. Controller actions are responsible for calling this
  method (or find_and_validate_access, which defers to validate_access)
  directly.
Return InsufficientScope error when the client is missing necessary
scopes

This commit changes the way that our `validate_access` helper enforces access to resources.
Access is determined in two ways:
- First, the client used to access the resource must have appropriate
  scopes. The scopes necessary to access a particular resource are
  defined in the resource's access class, in a method with form
  `<action>_with_token?`. The action passed to `validate_access` is appended
  with `_with_token?` before being passed to Allowy. For example,
  enforcment of scopes on the read action for an App resource is found
  in the `read_with_token?` method in the AppAccess class (app_access.rb)
- Second, the user must have access to actions on the resource as defined
  by the usual methods in the resource's access class. For example,
  enforcement of authorization on the read action for an App resource is
  found in the `read?` method in the AppAccess class (app_access.rb)

We also included a few minor refactoring/renames. In particular, the
upload action in the buildpack_bits_controller now uses the same name
(instead of :read_bits) to determine access.
Service instance permissions endpoint allows
cloud_controller_service_permissions.read scope in addition to
cloud_controller.read

[finishes #68037500]
Remove unnecessary check for write scope

This action is only permitted for admin users
Clarify language/setup in specs
Remove job_access class.

This code is unused. The JobsController allows unauthenticated access, and does not use any of the valide_access methods from model_controller, so the JobsAccess is not needed.
Remove authentication logic from ShardDomainAccess

All authentication logic happens during the check_authentication method
-- before this access class is ever used. Because the desired behavior
is that any authenticated user can perform the read action on the class,
the access class does need to check any user permissions and only needs
to return true.
Refactor and backfill some tests
Merge pull request #221 from cloudfoundry/feature/service_instance_scope

Feature/service instance scope
Add cloud_controller_service_permissions.read scope to uaa clients created during broker registration
Fix flaky spec

Signed-off-by: Michael Fraenkel <fraenkel@us.ibm.com>
Use p545 in Travis

[#70696726]
Revert "Remove buildpack_name and buildpack_guid from app usage events."

This reverts commit d5254becab0607830fc6e1945b5e40bf8dfefaa6.
Create a 'BUILDPACK_SET' app usage event

App usage events are currently created every time the desired state of
an application goes from STARTED to STOPPED or when the desired instance
count or memory allocation of a STARTED app changes. A requirement has
been raised to add buildpack information to these events but the
buildpack data is not always known at the time the desired state of an
app transitions to STARTED.

Since there are hard requirements to have events associated with the
existing STARTED and STOPPED states created without introducing windows
where events are duplicated or recorded out of order and to ensure that
events are immutable, the tactical resolution was to introduce a new
state called BUILDPACK_SET that represents a simple buldpack update.
While not ideal, it surfaces the information without breaking existing
code that depends on the STARTED and STOPPED events.

This change records app usage events containing buildpack information
when staging completes.

[#69196650]