Refactor AuthTokens to improve process of adding new IdPs

[gregcorbett]

Adding a new IdP feels more cumbersome now we have identity linking (maybe it's always been somewhat cumbersome).

The new IdP has to be added in three place.

1. MyConfig1.php to enable GOCDB to resolve the info the new IdP gives it into an ID String
2. A mapping of AuthTokens to authentication realms hardcoded in the User Service.
3. In the PI code in order to expose the new ID Strings to the outside world.

I think point 2 can be addressed with some refactoring of the AuthTokens, such that one AuthToken class corresponds to one IdP. Though this is probably best attempted once we have dropped shibboleth support and only support OIDC. One AuthToken can then correspond to one authentication realm and the getAuthTypes could loop through $myConfig1->getAuthTokenClassList(); to determine a list of possible auth types - similar to what it does now, but without the need for the hardcoded mapping in this file (pushing it into the tokens - which feels like a better place for it).

I think point 3 could be solved in a similar way, by referencing $myConfig1->getAuthTokenClassList(); and a mapping in the token itself between AuthToken and API XML tag.

[gregcorbett]

Related: #324 (comment)

it seems a bit lazy to go to the trouble of creating unique, name-spaced authentication class identifiers and then just check the short substrings Shib, X509 and IAM.

[gregcorbett]

I think point 2 can be addressed with some refactoring of the AuthTokens, such that one AuthToken class corresponds to one IdP.

#430 goes some way to achieving this for OIDC based integrations