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
new spec for the version 2 of the protocol

some new messages have been introduced and GET returns now an extra record
(which can still safely ignored by older protocol implementations)
minor changes to the spec
definitions for the new messages
introducing shardcache_get_multi() arc_lookup_multi() and arc_lookup_nofetch()

on the way of supporting GET_MULTI commands down to the storage level

(for now implementing the support at the cache level)
some more work (still in progress)
mark the "missing" objects as being locked (they are going to be fetched straightaway)

+ minor tweaks
extending the definition of the SET command by adding an new optional parameter

which, if present and not-zero, determines the cache-expiration time for the newly set key.
allow to force/set the cache expiration time when using the shardcache_set_async() interface
more notes
ensure using uint64_t instead of size_t

to store the lists size (and related counters) in the underlying arc implementation
fixed the documentation for the fetch_multi callback
implementing message-handling forthe new protocol v2

    - API changes: all the _async() functions have been droppedin favour of
      a more generic API which defaults to asynchronous operations and behaves
      synchronously only if no callback has been passed (only exception for the
      get and offset operations for which instead an explicit synchronous interface
      has been provided to not make the default interface too complex.
    - implemented the CAS command
    - implemented the *_MULTI commands

(WIP)
make it compile (even if not working yet *WIP*)

* replica support still needs to be reviewed after the last changes to the public (and private) API *
typo
support replication of CAS commands
cleanings + stricter protocol definition