On some systems, string.h declares basename().  This emits a shadow
warning.  Change the variable name.

{song,dir}vec_for_each each failed to gracefully handle deleted
files when iterating through.  While we were thread-safe, we
were not safe within the calling thread.  If a callback we
passed caused sv->nr to shring, our index would still increment;
causing files to stay in the database.

A way to test this is to remove 10 or so contiguous songs from a
>10 song directory.

Like the songvec nr_lock, only one lock is used for all
traversals since they're rarely changed.  This only
projects traversals, but not the individual structures
themselves.

We definitely don't modify them here.

This will make it easier to introduce locking

GLib's g_path_get_basename() is much more reliable than
mpd_basename().  The latter could be tricked into an assertion
failure.

Found by Valgrind while looking for another bug...

Hmm.. I should really just make this code generic since
they're duplicated...

It is invalid to pass a path with the wrong dirname to dirvec_find().
To be able to find a subdirectory only by its basename, compare only
the basename of both paths.

dirvec_find() does not modify the object, thus it should get a const
pointer.

CamelCase is ugly, rename the functions.

When there are standardized headers, use these instead of the bloated
os_compat.h.

The struct can be forward-declared by other headers, which relaxes the
header dependencies.

Having all functions as static (non-inline) functions generates GCC
warnings, and duplicates binary code across several object files.
Most of dirvec's methods are too complex for becoming inline
functions.  Move them all to dirvec.c and publish the prototypes in
dirvec.h.

Small memory reduction compared to songvec since most users have
much fewer dirs than songs, but still nice to have.