Because drw_scm_create() allocates it.

XUngrabKey(), which is currently used in cleanup(), is not the right
counterpart to XGrabKeyboard(), which is used in grabkeyboard(),
called from main().

XUngrabKeyboard() is the function to use, as grabbing the whole
keyboard is different to grabbing individual keys.

With the current code the keyboard gets ungrabbed, as far as I can tell,
only by the final XCloseDisplay() in cleanup(), as the XUngrabKey()
there effectively does nothing.

1. use `unsigned int` to store the codepoints, this avoids waste on
   common case where `long` is 64bits. and POSIX guarantees `int` to be
   at least 32bits so there's no risk of truncation.
2. since switching to `unsigned int` cuts down the memory requirement by
   half, double the cache size from 64 to 128.
3. instead of a linear search, use a simple hash-table for O(1) lookups.

When embedded into another window, dmenu will fail with the BadMatch
error if that window have not the same colormap/depth/visual as the
root window.

That happens because dmenu inherits the colormap/depth/visual from
its parent, but draws on a pixmap created based on the root window
using a GC created for the root window (see drw.c).  A BadMatch will
occur when copying the content of the pixmap into dmenu's window.

A solution is to create dmenu's window inside root and then reparent
it if embeded.

See this mail[1] on ports@openbsd.org mailing list for context.

[1]: https://marc.info/?l=openbsd-ports&m=168072150814664&w=2

Improves upon commit 32db2b125190d366be472ccb7cad833248696144

The getline() implementation often uses a more greedy way of allocating memory.
Using this buffer directly and forcing an allocation (by setting it to NULL)
would waste a bit of extra space, depending on the implementation of course.

Tested on musl libc and glibc.
The current glibc version allocates a minimum of 120 bytes per line.
For smaller lines musl libc seems less wasteful but still wastes a few bytes
per line.

On a dmenu_path listing on my system the memory usage was about 350kb (old) vs
30kb (new) on Void Linux glibc.

Side-note that getline() also reads NUL bytes in lines, while strdup() would
read until the NUL byte. Since dmenu reads text lines either is probably
fine(tm). Also rename junk to linesiz.

Keep track of the amount of items (not a total buffer size), allocate an array of
new items. For now change BUFSIZ bytes to 256 * sizeof(struct item)).

Maybe too obvious / redundant, but OK.