Max size is now 32K.

we needed to release ALL resources (including file handles!) only
after the the async writer thread has terminated (else it may access
them). In this case, we had a file handle leak, because the handle was
sometimes only opened in the async writer, but the close was attempted
before the writer even started (in some cases).

...after we seem to have identified the root cause of the segfault.
I leave them commented out so that we can re-activate it if need
arises (aka "get some practice drill first").

Most severely affected omfile. The problem was that some buffers were
freed before the asynchronous writer thread was shut down. So the
writer thread accessed invalid data, which may even already be
overwritten. Symptoms (with omfile) were segfaults, grabled data
and files with random names placed around the file system (most
prominently into the root directory). Special thanks to Aaron for
helping to track this down.

if the buffer was too small, we would see more API calls, but no
failure, so this is no fix!

Problems could lead to abort and/or memory leak. The module is now hardened in a very
conservative way, which is sub-optimal from a performance point of view. This should
be improved if it has proven reliable in practice.