Fix CAS to handle dynamic auth links

Fix CAS to handle dynamic auth links

CAS uses a "service" URL to redirect a user back to where an application wants
them to go if authentication is passed. This works well for simple URLs but
becomes problematic for complex URLs, which can get mangled or, worse,
truncated. This doesn't seem to be unique to Windsor's implmentation of CAS.

I tried a few tricks to encode the URLs in strange ways to get the same
URL back from CAS, but I think a better approach is to stuff the URL into
a cookie, and invoke when the request comes back from CAS. Any other approach
seems to result in horrid URLs and there is always the chance that some
character will break the scheme.

One flaw in my approach is that if a TPAC user selects "email" or "place hold"
and invokes the logon screen, the cookie gets set for the "redirect" URL. If,
for some reason, a user decides to do another search and chooses to log in to
their account from a different screen, the CAS URL can be invoked. This
would only happen for CAS, and the cookie itself is only set for 10
minutes, so I don't think this is a major concession. I also try to
invalidate the cookie wherever it is possible to know that the authentication
has not been invoked.

The assumption is that there is a CAS link added to the login form (login/form.tt2),
for example:

 <a href="[% ctx.cas.url %]"
    class="opac-button opac-button-header" id="home_myopac_link_uwin">
    [% l('Log in to Your Account (UWind ID)') %]
 </a>

I had become so used to testing CAS by logging in first, that I totally missed
the links that support authentication at the time of need, e.g. the "email"
or "place hold" links that are displayed prior to authentication. Hopefully,
this branch will address what is probably a common scenario.

Signed-off-by: Art Rhyno <art632000@yahoo.ca>