94370835 implemented one good and one bad idea.
The good idea was that it does not make sense to spin on an empty LRU list, so
if it is empty, we block on a condition variable, which gets signalled whenever
anything is added to the LRU.

The bad idea, however, was to also wait for more additions to the LRU list when
we failed to lock any fco on the list: They all could be blocking on the lru
mutex, and there is no guarantee that any more entries are to be added to the
LRU.

The new strategy now is:

- If we hit a failed trylock on an FCO, it is unlikely that the next element on
  the list is a different fcs type for the same fco (they should end up on the
  lru list _before_ the FCO), so we continue iterating, because we will likely
  succeed with the next element.

- If, however, we hit a failed trylock with a non-FCO fcs type, it is very
  likely that more fcses of the same fco follow. So far, we skipped these and
  avoided the additional trylock, yet iterating the list still costs time.

  The missed point was that, for a failed trylock, the fco lock owner likely
  blocks on a mutex lock of the lru lock, so we really should return it and
  re-enter list iteration.

A quick look into the internets suggests that mutexes should be fair-ish, such
that the LRU thread re-aquiring the lru mutex before any other waiters should at
least not be a primary concern:
https://pubs.opengroup.org/onlinepubs/007908775/xsh/pthread_mutex_lock.html
found via
https://blog.firetree.net/2005/06/22/thread-yield-after-mutex-unlock/ :

	"(after) pthread_mutex_unlock() ..., the scheduling policy shall
	determine which thread shall acquire the mutex."

Likely fixes #93