SSP-854 Fix race condition in current Person lookup/access.

Person, a Hibernate entity with *many* associations, was being stored
in SspUser which is SSP's SpringSecurity UserDetails object, which
ends up cached in the web session. So all threads that access a web
session get the same SspUser and *theoretically* the same Person. But
you can't actually use the same Person across web requests (threads)
b/c its proxied/lazy loaded associations are disconnected from the
original Hibernate session. And Hibernate entities aren't supposed to
be threadsafe anyway. So there was an attempt in the existing code
to re-look up the Person if SecurityServiceImpl#currentUser() noticed
that the Person didn't belong to the current Hibernate session.

But that attempt to re-look up the Person led to a race condition where
the current thread could still end up accessing a Person owned by
another (now closed) Hibernate session.

E.g. threads A and B... maybe both spawned by concurrent AJAX requests
from the same page and thus referencing the same web session. Thread A
gets the current SspUser, notices that Person does not belong to its
Hibernate session so goes to look up that Person again. Meanwhile the OS
schedules Thread B, which also notices that the Person does not belong
to it and starts is own lookup. Thread A resumes and sets its new Person
(X) into the current SspUser, then is suspended. Thread B resumes and
sets its new Person (Y) into the current SspUser and completes is work,
closing its Hibernate session. Thread A resumes, thinking that SspUser
holds Person X, but it actually holds Person Y, which is bound to a
closed Hibernate session. So any attempt to resolve lazy fields on
Person Y error out.

The fix was to make Person a ThreadLocal on SspUser. This did introduce
an interesting problem with write operations where the current
user was not looked up until very late in the request - during a
Hibernate flush - which led to StackOverflowExceptions for reasons
outlined in SspCurrentUserInterceptor, which is the fix for that
problem. Now we try to ensure the current user is the first thing
that happens in every request.

Note that this fix does imply that each request now incurs some
performance penalty, esp read operations that previously could avoid
looking up a Person. This is potentially not as minimal as it sounds
since we do know that Person lookups are quite expensive as currently
factored.
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.