Sorting songs by file name does not make much sense.  Most of the
time, users want to add songs in track order to the playlist.

Path names in the directory and song structs are always encoded in
UTF-8.  Don't use strcmp(), it cannot handle UTF-8 characters
properly.  Use GLib's UTF-8 aware g_utf8_collate() function for that.

{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.

We definitely don't modify them here.

Found by Valgrind while looking for another bug...

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

We only need to lock sv->nr changes to prevent traversals ( why
it's called "nr_lock").  free(3) is a "slow" function on my
system; so we can avoid unnecessarily holding a lock long for
longer than needed.

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

Again, a data type which can be forward-declared.

Pass const songvec pointers to songvec_find() and songvec_for_each().

Only one lock is used for all songvec traversals since
they're rarely changed.  Also, minimize lock time and
release it before calling iterator functions since they
may block (updateSongInfo => stat/open/seek/read).

This lock only protects songvecs (and all of them) during
traversals; not the individual song structures themselves.

This is so we can more consistently deal with locking
needed for thread-safety in iterator functions.

We don't modify the Song when we delete it

"free" implies the songvec structure itself is freed,
which is not the case.

Potentially broken free() implementations don't like it

Any pruned files will be noticed during update and pruned
from the live database, so this inefficient function can
go away and never come back.

Our linked-list implementation is wasteful and the
SongList isn't modified enough to benefit from being a linked
list.  So use a more compact array of song pointers which
saves ~200K on a library with ~9K songs (on x86-32).