Attributes in SAML View Filtered by Attribute Policy

Deals with https://github.com/Jasig/cas/issues/722

## What's this for?
The intention of this pull is of course to make sure SAML attributes pass through the attribute filtering policy, so each service only gets what it was allowed to receive. The fix fairly trivial and requires the principal be retrieved from the primary authentication rather than what's in the chain.

## What's the other stuff for?
As is mentioned in the issue, I was hoping to find a consistent approach so that each view would not have to manually populate the model, execute login to convert attributes, or to know about which authentication object to use, etc. The idea is that when a view renders, it should everything it needs in order to render correctly without any additional code or handling logic...and that all views should get what they need from the same place so we would duplicate code and possible inconsistencies and arguments over which thing must be used from where, etc.

## How does that happen in this pull?
In summary:

- Our `AbstractCasView` has become the parent class and the authority over the model that is built by controller. It exposes various helper retriever methods that expose authentication, principal, etc into its extensions.
- Most other CAS views now extend from `AbstractCasUrlBasedView`, which allows one to delegate the actual rendering of the view to an inner-view (usually backed by JSTL), but they also allow the view model to be stuffed with stuff that it needs.
- I say "most", because some views don't delegate to JSTL. They simply just build the response right there in the view and write it back out.
- These protocol-level views where previously constructed and loaded by a properties file. They are now turned into legit beans so we could easily inject stuff in and out. 
- There are two new view classes for Cas20 and Cas30. Each view stuffs the model with the data it needs for the protocol level the class is for, and thereby cleans up the JSP file pretty good so it's clearer to see what's happening. One caveat of the approach is, that attributes in general for both authentication and principal, are turned into collections if they are not in one already. If the attribute is a collection, then it's fine. If it's just a single value, it's turned and put into a collection. This is ONLY done for rendering of the view and allows the JSP to simply for-loop over everything without having to worry about what attribute is a collection and what is not. 
Yes. Should the xmlViewResolver be uncommented and used, I wanted to make sure it has the right order. Anything that is based on `InternalResourceViewResolver` should be moved to the very last because it's a fallback that would catch everything.