CAS-1475: Refactoring of GoogleApps altUsername config

Fixes #466 

I started out with the original premise of this JIRA:

> The GoogleApps service currently declares a custom property to determine an optional and alternate username attribute to be sent back to Google. CAS 3.5.x adds the ability to configure username attributes per service, rendering the Google altUsername config unneeded.

https://issues.jasig.org/browse/CAS-1475

This pull request is the result of refactoring the usernameAttribute-per-service API that exists as of CAS 3.5. While I was working on the GoogleApps-related change, I realized that the determination of the uid per service is complected in CAS impl and is dependent on a number of other variables and settings in the registry that could easily be turned into logical abstractions, and used one at a time to simplify the configuration. This pull is the result of that effort. 

Aside from making sure the GoogleApps integration design-wise is consistent with the service registry config, my other goal was to attempt to reduce CASImpl's complexity, by taking one-off if-conditions and turning them into logical abstractions, and more importantly extension points. The idea for extension points was also inspired by a few recent projects where there were strict and rather complicated requirements for calculating the username for a given service that involved multiple systems, etc. So in part, the refactoring opens up the possibilty of not having to fork CASImpl but just to extend a class to encapsulate the logic needed for uid of a service.

The following is included in this pull:

### RegisteredServiceUsernameAttributeProvider
There are three possible options for a username returned to a service:

1) default principal id
2) anonymous id
3) principal attribute

Inspired by PersonDirectory, in this pull each registered service includes a `RegisteredServiceUsernameAttributeProvider`, and there are 3 possible implementations for the above points.   

### DefaultRegisteredServiceUsernameProvider
The default principal id, case (1), as the username...this is the default provider for each service.

### AnonymousRegisteredServiceUsernameAttributeProvider
Case (2)

### PrincipalAttributeRegisteredServiceUsernameProvider
Case (3)

To figure out the attribute, one would need to call from CASImpl:

```java
final String principalId = registeredService.getUsernameAttributeProvider().resolveUsername(principal);
```

Adopters of course would need to configure each service with the relevant provider. The default is used if none is configured.

Example:

```xml
<bean class="org.jasig.cas.services.RegisteredServiceImpl">
	<property name="id" value="2"/>
	<property name="name" value="EduPerson Test Service"/>
	<property name="serviceId" value="eduPersonTest"/>

	<property name="usernameAttributeProvider">
	    <bean class="org.jasig.cas.services.PrincipalAttributeRegisteredServiceUsernameProvider"
	        c:usernameAttribute="eduPersonAffiliation" />
	</property>    
</bean>

...

<bean class="org.jasig.cas.services.RegisteredServiceImpl">
    <property name="id" value="4"/>
    <property name="name" value="Test Service anonymous"/>
    <property name="serviceId" value="testAnonymous"/>
    <property name="usernameAttributeProvider">
        <bean class="org.jasig.cas.services.AnonymousRegisteredServiceUsernameAttributeProvider" />
    </property>
</bean>
                
```

### Management App



No, they most definitely are. Lets review the use case again:

1. Every service has a username attribute provider.
2. Users can configure a provider in the application context, and connect it back to the service.
3. Some providers like the anonymous username provider require an id generator, which by default is picked
4. If and when we choose to modify the management interface to allow adopters to configure username providers per service, they will be presented with a list of options for providers. They can go with a principal attribute provider, or with an anonymous one. 
5. The management interface does not have to support the id generator configuration if an anonymous username provider is picked. It could (and our statement could be) simply just go with the defaults....or it could support that. It's all a matter of how we choose to present UI options. 

It may be something like this:

1. I pick my provider to be anonymous, out of the options UI presents to me.
2. UI changes and says: by default this provider uses this ID generator, and here are its settings (salt, etc)
3. I change the salt and press save.
4. The configuration is composed to put everything together, and will be saved as a whole. Lob, or inmemory, etc.

(note that of course the UI options presented to the user do not have to match what is available in the context. We could spin up class instances ourselves with some kind of mapping for example)