Refactoring & design of role-based service authorization. 

Handles #798 

## Summary
This pull combines the authorization features of the services in the service registry into a single component that is `RegisteredServiceAuthorizationStrategy`. This interface exposes 3 operations that check whether a service is enabled, allowed to participate in SSO or can receive an ST based on required attributes. The default instance is  `DefaultRegisteredServiceAuthorizationStrategy`. 

## Role-based Access

An authorization strategy may be configured to require a bunch of attributes. This indicates that the given service can only be granted an ST if the principal contains the required attributes (any or all). The behavior is outlined as such:

 <ul>
          <li>If no required attributes are specified, authz is granted.</li>
          <li>If ALL required attributes must be present, and the principal contains all and there is
          at least one attribute value that matches the required, authz is granted.</li>
          <li>If ALL required attributes don't have to be present, and there is at least
          one principal attribute present whose value matches the required, authz is granted.</li>
          <li>Otherwise, access is denied</li>
 </ul>

Note that comparison of principal/required attributes is case-sensitive. Exact matches are required
for any individual attribute value.