Issue 468: Support for dynamic principal attributes

This fixes #468

# Summary
Based on the thread [here](https://groups.google.com/d/msg/jasig-cas-dev/...E/YLmczv0nieAJ), I have updated this pull with the following:

The idea of this pull request is to allow principal attributes to be cached for configurable period of time, as opposed to the entire length of the SSO session. This cache can be set to expire immediately, so attributes are always returned back as a fresh copy, or the timeout can be adjusted per the environment requirements and use cases.

Note that this behavior ideally may be considered an optional feature and should be turned on, if needed. Not everyone has a requirement to freshen up the state of attributes in CAS. 

# How
To do this, principal objects are no longer allowed to be created directly. Rather, they must be obtained. The "thing" that creates them will produce a proper principal type that is able to retrieve attributes for CAS, and is the entity that decides whether attributes are cached for this principal or not. 

`PrincipalFactory` implementations create `Principal` Objects. There is a default implementation that is `DefaultPrincipalFactory` whose job is to create a principal in a such a way that `principal.getAttributes`() would retrieve attributes from the underlying systems. 

The task of retrieving attributes by the principal is also abstracted away into an interface of `PrincipalAttributesRepository`, which defines must be done in order to get attributes. The factory can be injected a `PrincipalAttributesRepository`, so at the time a principal is created, it receives the configured `PrincipalAttributesRepository` instance.

```java
   @Override
    public Principal createPrincipal(final String id) {
        return new SimplePrincipal(id, this.attributesRepository);
    }
```

There are two attribute repositories:

 - `DefaultPrincipalAttributesRepository`: which is the existing behavior; simply returns attributes as it receives them. 
- `CachingPrincipalAttributesRepository`: One that caches attributes for a period of time.

Principals can then execute the following when attributes are requested, and depending on the type, either the original, a cached copy or a fresh set will be retrieved:

```java
    public Map<String, Object> getAttributes() {
        return this.attributeRepository.getAttributes(this.id);
    }
```

#`CachingPrincipalAttributesRepository`
This repository caches attributes based on JSR107 JCache. The back-ed by default is the JCache reference implementation (RI) although I have also added the dependency for Ehcache support. All one would have to do is to drop the RI (whether it's the default or ehcache, etc) on the classpath. The repository makes it easier to create configurable caches. Sample:

```java
//create repository with an initial set of attributes which would expire after 5 seconds
//forcing the repository to recollect them.
new CachingPrincipalAttributesRepository(this.dao,
                Collections.<String, Object>singletonMap("mail", "final@example.com"),
                TimeUnit.SECONDS, 5);
```

# Default
Default behavior is preserved.. The feature is entirely optional, and only needs tweaking if one wants to switch the principal factory instance:

```xml
<bean id="principalAttributesRepository"
 class="org.jasig.cas.authentication.principal.DefaultPrincipalAttributesRepository" />

<bean id="principalFactory" 
class="org.jasig.cas.authentication.principal.DefaultPrincipalFactory"
            c:attributesRepository-ref="principalAttributesRepository" />
```
This is very strange: why is the ```principalId``` not the key of the cache of the user attributes? How does it work for multiple users authenticating a the same time?