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
uint8_t