Low: implement common base for lib{xml2,xslt} log -> libqb handling
Several explanations:
- new-line termination of the finalized messages streamed from libxml2/libxslt may be imperfect (see https://mail.gnome.org/archives/xslt/2017-May/msg00001.html) hence the optional dechunking will consequently stagger as well, but the worst case is that such degenerate message is either joined with a subsequent or never emitted at all if such case never occurs prior to respective program termination, and for the invalid/mismatching arguments to hit the internal vasprintf invocation, we explicitly emit a note that log corruption may be imminent
- related to previous, message chunk allocated on heap but never properly finalized may result in a memleak, but the amount of memory allocated like this is proportional to the number of unique callsites using the implemented macro, exponential growth would only be possible either with seriously broken (accumulation of non-newline-terminated chunks) or malicious library, and we don't explictly guard against that cases because it's quite improbable (the potential problem and the bad-timing-of-shutdown subissue are noted in the comment, though)