Refactor to represent service types, claims sets and attribute "bundles" in the model classes

Give a 'type' to each service, `research` or `zendesk` to support existing services, and `auresearch` as a new type with a modified attribute set. Only changeable by administrators and not advertised in the application.
Clever little bastard :P But I figured out how this works, clever code. :trophy:

There is actually an issue here however in that we don't seem to have a way to reverse engineer who the original subject was if a service comes to us with the value they where provided and we need to figure out who it was that took the action (other attributes aside, lets assume they don't log them). Thoughts? Perhaps 'r' could also act as a key for principal ?