... a chance to take memory from the old

otherwise we would hold onto log blocks for a long time, possibly until
the next ref'ing flush. This could cause lock ups due to no memory being
available.

This is considered a major contribution towards fixing the lockup issues
documented in #41

kick the logwatcher first before potentially running into a synchronous
flush.

Related to #45

The oh-so-smart idea from 39c2568e was
pretty dumb after all:

While testing with the low RAM config (16MB on 10GB), a lockop was found
with only ~45% of RAM occupied. The reason for the lockup was the
un-crammed 64KB (16bits) request for a regionlist with priority 4, which
was blocking all other requests.

So: No, trying to allocate something "just in case" is never a good
idea.

It should allow log transactions to complete first

A pool tries to always have allocations ready. There are two buddy_reqs,
and when one is depleted, allocations are taken from the other, while
the empty reqs are being filled again.

such that the test can easily be run with 2>/dev/null if the dbg output
is of no interest.