filedescriptor-based API in shardcache_client

allows to retrieve data by using a filedescriptor so that
the caller can eventually register it in its own event loop

* TODO * documentation and cleanings
updated libiomux
better handling of the background thread for the fd-based interface
the async worker is used only when fetching a single item
updated dependencies
accumulate data in the get_multif implementation if not able to flush everything pending

+ some cleanings
use iomux timeouts on the managed filedescriptors

now that they are much cheaper to use
make a copy of the items to fetch in shardcache_client_get_multif

so that the caller can safely release the resources used to represent the input list
while we still have everything necessary to retrieve the keys asynchronously and provide
the data back on the returned filedescriptor
exposing getf() and get_multif() methods in the Shardcache::Client::Fast perl library

** UNTESTED **
get_multif
documenting the fd-based interfaces
test both the getf() and get_multif() interfaces
use 32bit integers in network byte order to encode the index and the size

of data being provided through a filedescriptor when using the get_multif() interface.

This is safer and ensure certainty even if limiting the datasize to MAXUINT
when retrieved using get_multif()
missing include statement
just a note
silence clang
don't hang if the response is shorter than expeceted
helper class to parse responses from get_multif() calls
output a warning message when a connection is closed because of a timeout

in both the asynchronous reader and in the client-side multi-fetch implementation
updated libhl