Since we switched from autotools to Meson in commit
94592c14, we don't need to include
`config.h` early to properly enable large file support.  Meson passes
the required macros on the compiler command line instead of defining
them in `config.h`.

This means we can include `config.h` at any time, whenever we want to
check its macros, and there are no ordering constraints.

This eliminates some overhead, because the compiler doesn't need to
consider these functions throwing.

Remove the C list_head library and use type-safe C++ instead.

Reduces overhead because we need to manage only one memory allocation.
According to valgrind/massif, we save 7%.

The given song must exist, or MPD will abort.  Calling it with an
unknown song is illegal.

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