Issue #460: TGT id to not be disclosed in logs

Fixes #460

## What is in this pull?
This patch binds against SLF4j APIs with a static binder that is provided by CAS. The CAS binder will pick the CAS LoggerFactory, which will create CAS loggers. The CAS logger itself is simply a wrapper/substitute logger around the "real" logger instance. 

## How are loggers selected?
The actual logger instance is picked from what's available at runtime. The CAS logger factory will scan the classpath for logger factory instances, will remove itself from the list and will attempt to use the first one that is found to construct the logger from it, and pass it onto the CAS wrapper logger. 

## How are ticket ids removed from the log?
The CAS wrapper logger will first remove the the ticket id from the log message, if any, and then will pass the message to the delegate/real logger. In our case, that is right now the Log4jLoggerAdapter or something like that :)

No changes to the CAS codebase, whatsoever.

Note: all components need to exist in the `org.slf4j.impl` for this all to work.

Sample output:

```bash
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [file:/Misagh/GitWorkspace/cas-server/cas-server-core/target/classes/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/portal/apache-tomcat/webapps/cas/WEB-INF/lib/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class
]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: ILoggerFactory to be used for logging is: org.slf4j.impl.Log4jLoggerFactory
SLF4J: Actual binding is of type [org.slf4j.impl.CasLoggerFactory]
SLF4J: The following set of substitute loggers may have been accessed
SLF4J: during the initialization phase. Logging calls during this
SLF4J: phase were not honored. However, subsequent logging calls to these
SLF4J: loggers will work as normally expected.
SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger
```
Not sure I follow your statement? What this is going to is attempting to log the exception message and the message itself at a TRACE level, having sanitized the log messages itself first.