Abandoning the idea of list ID

Replacing it with handler_t type

Pointer is an excellent key as is and as ID only was meant to find lists
easily, we were in practice inventing a memory allocator. No need as there
exists an excellent one already (malloc). We just hide the pointer to avoid
encouraging direct access.

Thinking of scrapping most of the mlib API. It can't work as to be
transparent, data has to be unknown in C (void*). Hence all the "new"
operators can be scrapped as they can't be sorted and it turns out using
them is unnatural.

add_last and add_first also feels strange if add is supposed to be sorted.
It could make sense if compare function is missing I suppose, but should
lead to deliberate error.

Instead one would like to add new functions:
lseek(offset, from-position)
search

Category: development.
Make it so

Category: development
libmlist: Separated source in separable files

Separation is done to keep each part smaller and easier to grasp, but also
following some relevant logic:

initfini.c    /* Code involved with initializing and destroying global data
                 when library/module is loaded/unloaded */
modglobals.c  /* Administrative and global data. Could have resided in one
                 of the C-files, but this makes it structurally easier to
                 find */
 mlist.c      /* The rest in the original mlist.c is the public API
                 implemented */

Category: development
Custom vimrc files added

Per directory a .vim.custom is added. This helps run the debugger and to build
correctly. The following lines are needed in ~/.vimrc

if filereadable(".vim.custom")
    so .vim.custom
endif

Category: development
libmlist:

* listheader structure finalizes

Category: development
libmlist: Structure for list-container finally in place

Both data and code is starting to flux less. Good enough for continue
without finalizing it as libmlist is an ambitious project on its own with
support for reentrant calling and multi-threaded access Can't be fully as
references (i.e. pointers) can't be safe without working with copies and I
don't want that as list access needs to be fast lighting fast. Support will
work on protecting internal structure during creation and deletion, which is
perfectly good as long as one understands that additional synchronisation is
needed depending on use-case.

Embryonic functionality of the sampler engine, i.e. threads created by
create_executor.

Category: development