Introduces wrappers around memory allocation functions in `memory.h`
that should be used instead of the standard C ones.
These never return NULL and, with the exception of `mem_realloc()`,
zero-initialize the allocated memory like `calloc()` does.
All allocations made with the memory.h API must be deallocated with
`mem_free()`. Although standard `free()` will work on some platforms,
it's not portable (currently it won't work on Windows). Likewise,
`mem_free()` must not be used to free foreign allocations.
The standard C allocation functions are now diagnosed as deprecated.
They are, however, available with the `libc_` prefix in case interfacing
with foreign APIs is required. So far they are only used to implement
`memory.h`.
Perhaps the most important change is the introduction of the `ALLOC()`,
`ALLOC_ARRAY()`, and `ALLOC_FLEX()` macros. They take a type as a
parameter, and allocate enough memory with the correct alignment for
that type. That includes overaligned types as well. In most
circumstances you should prefer to use these macros. See the `memory.h`
header for some usage examples.
This shouldn't be needed, as according to the Linux inotify(7) man page,
the entries are supposed to be aligned. It looks like libinotify-kqueue
doesn't respect this and doesn't properly zero-pad the name field.
It's now based on directory monitoring, which is more complicated, but
also much more reliable, especially when dealing with move events and
hard links. It is also closer to the semantics we actually want
(monitoring fs paths for changes, not inodes). It will still get
confused if the directory itself gets moved (directly or indirectly),
though, but handling that correctly is absurdly difficult and not
important for our use-case.
Importantly, FileWatch no longer becomes useless after reporting a
FILEWATCH_FILE_DELETED event: if another file is placed onto the same
path later, the FileWatch will report FILEWATCH_FILE_UPDATED. Some
client logic can be simplified because of that.
