Artwork caching alternate variant

Based on #58 this pr adds one commit combining the daap cache and the artwork cache.

@ejurgensen I am not sure if this goes into the direction you have in mind. It's not finished and only meant to show how an approach to combine the two caches could look like, using a thread and a single cache db. I did only a short test and it seems to be working.

I have to say, i really do not think this is a good solution. I agree that combining the two caches makes sense. The two ways to combine them (i can think of) are:

1. Merge the artwork cache into the daap cache (started in this pr). This uses a thread and an eventbase listening on a pipe. It executes requests to the caches one after the other. The cache thread is the only one accessing the cache db. 

2. Merging the daap cache into the artwork cache. Removing the cache thread and accessing the cache db directly from each thread. The rebuild of the daap cache could be seen as part of the filescanner thread.

I think the main disadvantages of (1) are:
- the cache thread is only active, if another thread is waiting for its result (reading/adding to the daap or artwork table). This means this thread is not used to execute code in parallel to the other thread, but adds complexity and uses additional resources.
- reading and debugging the code gets more complex. Stepping through the code becomes harder due to the thread switch. The functions in the cache get a command struct and therefor its not obvious which parameters they expect and which results they return (e. g. the evbase is in one case a parameter and in another a return value).
- even if parallel request to the cache do not intersect on the db one is blocked until the other finishes

I am not noticing db locking running forked-daapd, and in case of the cache it should be very unlikely to happen as there should not be long running queries.

From a users point of view there will probably be no noticeable difference between the two approaches. 
Even so i think (2) will use less resources and offer better performance (in theory), as it does not spawn an extra thread and does not use an additional eventbase.

@ejurgensen let me know what you think of it and which direction you want this to go
For filesystems that do not provide a valid last modified timestamp the cache will currently be never updated. A way around this is to only call "cache_artwork_ping" if mtime > 0. This will result in deleting the whole cache for such filesystems. 

The ping was necessary for the first variant of the cache (there the delete was only done if the update was not done inside the bulk scan) and is still used to identify the cache entries for no artwork available (the call to "cache_artwork_purge_cruft" at the end of the bulk scan). 
As you suggested, this could be changed by removing the update and modifying the delete query in "cache_artwork_purge_cruft". Changing this might make it more difficult to add support for filesystems with mtime = 0. I guess, the modified timestamp of the artwork file must be stored in the cache, so that the delete in "cache_artwork_purge_cruft" can delete all cache entries with a timestamp = 0.

I tried to answer in the forum thread, but got the message that my post needs the approval of a moderator.

To identify the problem with missing artwork, it would be helpful to check, if forked-daapd actually identified the emebedded artwork by looking into the db:

    sqlite3 /var/cache/forked-daapd/songs3.db
    .load /usr/lib/forked-daapd/forked-daapd-sqlext.so
    SELECT artwork, songalbumid, path FROM files WHERE path LIKE '%somefile.mp3';

And the user should delete the cache.db file, to make sure the songalbumid is not already cached, before making the debug log with the acutal request for the artwork.