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-843 Remove test for deleted controller method