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



That's sort of what I am saying, yes. In a sense, what's configured in the Spring configuration is one thing, and the configuration required to put services into a database is another. You cant have them both ways (i.e. If you are going to manage services via a DB/interface, why are you changing xml files around?!) or yes, stuff would get out of sync. 

We provide a template configuration, as you say, in the context. This is how stuff would work OOTB normally. If one is going to change the backend to be something other than memory, that configuration no longer applies and needs to be moved over to that place (which is what the management app does) The current behavior today works in the same way. If I have 3 services in xml and I decide to put them in ldap, if I configure my ldap mapper, etc my services aren't going to show up in ldap automagically...at least I dont think they will! :)