SSP-854 Fix memory leaks in SspUser-Person bindings

Since the Person field on SspUser was changed to a instance-scoped
ThreadLocal, I started seeing warnings about abandoned Person
ThreadLocals on Tomcat shutdown. Basically every login would result
in an abandoned Person that wasn't being GC'd. This had mainly
to do with the fact that SspUser users could be created and
disposed of several times during a given request without any cleanup
that would free ThreadLocal resources associated with those
instances. There was also a bug in the previous commit for SSP-854
where the ThreadLocal would be set for the session-scoped SspUser
before the Spring RequestAttributes would be populated, but then
once the RequestAttributes *were* populated, it obscured our
ThreadLocal and the latter was never cleaned up.

Unfortunately, as noted in the code, we couldn't just switch to
a static ThreadLocal b/c SspUsers aren't used exclusively to
represent the current user bound to the request. For the same reason,
trying to use Spring RequestAttributes in the first place was also
misguided.

So I switched to using our instance-scoped ThreadLocal field exclusively
and dispensed with all the RequestAttributes handling. This exposed
another issue where a Person would be looked up at login by the
SpringSecurity stack before our OpenSessionInViewInterceptor fired,
resulting a Person from the wrong Hibernate session being bound to the
"current" SspUser. So I removed our OpenSessionInViewInterceptor in
favor of a servlet-level OpenSessionInViewFilter.

Also introduces a registration mechanism on SspUser that basically
tracks every invocation of SspUser#setPerson on a static ThreadLocal
so we can clean it up at the end of every request. The cleanup is
handled by portlet and servlet filters.

Also modified our Spring-scheduled methods to ensure that they call
the SspUser cleanup mechanism when they complete. To get this to
work properly and ensure the cleanup occurs outside the scheduled
method's transaction/s, I had to refactor the actual @Scheduled
methods into a separate interface.