educast: Fix possible deadlock spanning DB transaction and caching lock with user references

The JpaUserReferenceProvider#updateUserReference updates an in-memory cache as part of the DB transaction context.
Putting something in the cache will acquire a lock on the cache. If the JpaUserReferenceProvider#loadUser method is
called after the start of the DB transaction but before putting the object in the cache, the cache loader will try to
read the user reference from the DB and put it into the cache if it cannot be found (e.g. after a Opencast startup).
This also requires a lock from the cache but will block in the DB since the DB transaction is already running. Since
this deadlock uses in-memory Java locks, it cannot be detected by the DB and the DB transaction will not be canceled.

This moves the cache update outside of the DB transaction context. When multiple user reference updates run at the same
time there is still a race to insert into DB/cache. However, in practice the user reference is probably the same except
for the last login date.