UP-4265 Improve logging around profile selection

This changeset bundles up logging enhancements that were added to MyUW in the course of profile mapping troubleshooting and offers them into the uPortal product.

Most of the new logging is at `TRACE` or `DEBUG` level so for most uPortal configurations this will have little effect, but adds latent logging useful for troubleshooting profile selection and session handling issues.

SessionAttributeProfileMapperImpl responsible for storing session attribute
========================

The only substantive change in this changeset is to move responsibility for storing the session attribute remembering the user's requested profile out of the `/Login` handling and into `SessionAttributeProfileMapperImpl`.  What session attribute that's stored into becomes an implementation detail of that profile mapper, and if that profile mapper isn't available ( `@Autowired` into the `/Login` handling) then there's no need to store that attribute.

Logging added throughout
====================

Where no existing logging or existing `slf4j` logging, uses `slf4j` API and log style with placeholders and un-gated `logger.trace()`.  Where existing logging using the inferior Commons Logging API, didn't rock the boat and uses Commons Logging style String concatenation with `log.isTraceEnabled()` style gating.

Example of resulting log
==================

An example of configuring the components for `TRACE` logging and the resulting output from a request for `http://localhost:8080/uPortal/Login?profile=respondr` is available [in a gist](https://gist.github.com/apetro/055f18c6562ec879fd42).
- The cost-benefit on the future-proofing vs code readability on getClass().getSimpleName() seems poor.

Quite the opposite actually. Rather than relying on love and tenderness and human nature, it's a lot more practical to rely on the IDE, to automate this process with a global refactor/rename operation that would take care of everything. Plus, in many of these toString() calls the name of the class is not accurately reflected, and that might cause a bit of confusion.

...and you shouldn't have to use this.getClass() per se if you are worried about readability. Use the name of the class statically, to both note the correct class name and take advantage of static typing benefits.