Add list_for_each_lock(); Few List bugfixes

This is the first commit in a row of quite some which grew the last few days
in this repository. I try to add them in a topic domain not in the actual
chronological order.

list_for_each_lock() was added to simplify the task of counting list
elements which occurs multiple times in the sources.

Fix a typo (';' -> ',') in list_for_each_data_safe().

Make List destroy the mutex it creates.

Fix list_for_each() usage bug in unlink_nodes(). Using this macro with
'first' (being a node) as head parameter will initialise 'last' to be
first->next which can be 'head' again. The function will thus return NULL,
even if 'num' was given 1 and the call would therefore be legal.
Ensure ABI compatibility in Hook; some Hook fixes

User-defined hooks start at 64 now to guarantee ABI compatibility with new
engine hooks introduced.

Don't initialise unused hook slots with lists.

Fix two deadlocks in hook.c which were exactly the problem with break or
return in a list_for_each* loop I was talking about in a previous commit
message (865a9620). *Sigh*
No __exit cleanup in do_die(); begin Trace restore

Trace now checks string arguments and doesn't try to strlen() or print them
if they're NULL.

Begin proper Trace handling from insert_module(). The issue: setjmp() in
insert_module() leaves traces in the trace stack. The anticipated solution:
a separate buffer ('marker') which can be used to reset the trace to a known
state. This is not implemented at present but prepared by the
RESTORE_TRACE() macro.

Do not call __*_exit functions from do_die() anymore because there is no
sane way of dying: held locks could be just everywhere, like mutex's
internal spinlocks, list mutexes etc.. I suspect that in case of do_die(),
there isn't much need for uber-cleanly exit.
Random types/ fixes; severe ones for Stack

Forbid creation of zero-sized ring buffers which could potentially DoS the
engine in is_ring_full().

Fix stack.c synchronisation issue of stack->end when stack->elements was
moved by realloc() which screwed up the trace sometimes when the stack had
to be resized.

Remove 4 elements in a chunk when they become free in a stack just like we
do when allocating them.

Update queue to use new List interface.
Try to find non-traced functions

The added script prints all non-traced functions.
Design Event loop; Revisit Module

Module loading and the event loop interact closely. I decided that future
threads will have to be stopped occasionally to sanely approach the whole
issue of synchronisation within the engine. One of these ocassions will be
the insertion of a new module. But this is not carved in marble yet since
there is no Thread API at all which the idea can be tested against - new
event sources are due before we can think about threads, still.

It seems that initf and exitf must not be on the stack in insert_module()
because setjmp() restores the stack context and thus invalidates their
correct values. Quite true and all that, I just wonder why the error didn't
show up earlier... However, I packed all related stuff into struct module
which now also saves the given 'uptr' correctly (it didn't before for the
same reason as stated for initf and exitf).

Steady modules still produce memory leaks - why?
Remove exit_onces; assimilate List in subsystems

Remove all struct once from __*_exit functions because the event loop and
thread design (in the future) will allow to bring down the engine to
single-thread operation before it's going to exit. (*This is one prominent
case of a commit message which is out of its chronological order. It makes
more sense if you take this message before the one of commit f0547867.)

Use new List interface in Config and Filetype.
Make test module be playable; update version

Adding -rdynamic to the engine's CFLAGS makes its symbols available to
modules.

The modules/test/ compiles and executes fine now.

Cleanup Document/build.txt and explain the new versioning scheme. verion.c
implements it now.

Update VERSION and API_VERSION to reflect recent changes - and hey, the
engine is finally able to play modules again. It's not very pretty but a
start whose interface can now be broken again :-)

Only steady modules produce memory leaks (for still unknown reason).