remove the custom allocator

[DerDakon]

• it's as simple as possible, probably intentional. This makes things like alloc_re() (i.e. realloc()) inefficient as it does not look if the thing it reallocates is already the last thing in the batch, and simply extends that, or if alloc_free() has the last block and adds things back to the pool (ideally with zeroing for security reasons).
• it makes it basically impossible to detect overruns on early small allocations with tools like valgrind, address sanitizer or friends as those allocations never hit malloc(), so are never traced by any custom tools. Any overrun will just go into the next variable, untracable.
• allocators do their own buffering, alignment, and so on. If they are broken, your system is severely screwed. And if we need more money^H^H^H^Hemory we will hit that buggy allocator anyway, making things harder to detect as it will only happen on "heavy" memory usage. This is not TruOS, SunOS 1.x or something like that anymore. We expect a reasonably sane OS. Everything else will get us screwed in much more severe ways.
• it has shown issues when coming close to 4GiB allocations (fix overflow in alloc.c #37, fix possible integer overflow in alloc() #109, older reports). DJB correctly says that an allocation of that size in your mailer shows that you have already done something wrong, but still: 64 bit platforms are the default, so using a 32 bit type to pass allocation sizes is a bug of it's own.
• when any additional patch accidentially mixes calls to this functions with normal realloc()/free() this can lead to random crashes
• why bother at all with having a custom allocator?

Fixes #112

[schmonz]

I find the motivation for doing this very strong. The sooner we can turn on Valgrind and ASan in CI, the sooner we can be systematically ratcheting safety upward.

[DerDakon]

We have 2 possibilities: either merge #113 first, which renames the usages of alloc in cdb code, or we just remove it. Either way, we have to touch that anyway as otherwise the alloc there will be changed from the define to malloc, which would also affect the function parameter. IMHO the best thing is to just remove that entirely and use malloc() directly as there is no need to pass that as function pointer here. Afterwards the alloc(x) version of the define can be used again.

[schmonz]

Same as previous