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



I am afraid that wont work, because it's just enough to store the object type. We need to keep track of everything that object was carrying with it. For example:

```xml
<bean class="org.jasig.cas.services.RegexRegisteredService"
              p:id="10000001" p:name="HTTP and IMAP" p:description="Allows HTTP(S) and IMAP(S) protocols"
              p:serviceId="^(https?|imaps?)://.*" p:evaluationOrder="10000001">

            <property name="proxyPolicy">
                <bean class="org.jasig.cas.services.RegexMatchingRegisteredServiceProxyPolicy"
                      c:pgtUrlPattern="^(https?)://.*" />
            </property>

            <property name="attributeReleasePolicy">
                <bean class="org.jasig.cas.services.ReturnAllowedAttributeReleasePolicy">
                    <property name="allowedAttributes">
                        <list>
                            <value>uid</value>
                            <value>groupMembership</value>
                            <value>memberOf</value>
                        </list>
                    </property>
                    <property name="attributeFilter">
                        <bean class="org.jasig.cas.services.support.RegisteredServiceRegexAttributeFilter" c:regex="^\w{3}$" /> 
                    </property>
                </bean>
            </property>
        </bean>
```

When we are persisting proxy or attribute policy, it's not enough to store a key mapped to the type name. We'll need to be able to carry in everything that object had. We need a representation of that object as is; the object will be serialized, we just walk about how and in what format I guess. 

I am imagining the UI would be able to very nicely lay out all options that one could have for proxying or attribute policy, and these all would be strings and lists, etc passed from the UI layer to the backend. A collection of strings and flags that would ultimately construct the object snippet you see above. 

Now we could:

1. Start creating fields for every setting and property, and store things as strings. retrieve them, and create the object manually based on those values

2. Persist the entire object, and pull it out as is.