After we've been hit by Large File Support problems several times in
the past week (which only occur on 32 bit platforms, which I don't
have), this is yet another attempt to fix the issue.

When the songs of two albums are in the same directory, all songs of
an album should be right next to each others.

Moved some code to tag_get_value_checked(), to eliminate several NULL
checks.

This updates the copyright header to all be the same, which is
pretty much an update of where to mail request for a copy of the GPL
and the years of the MPD project. This also puts all committers under
'The Music Player Project' umbrella. These entries should go
individually in the AUTHORS file, for consistancy.

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