version bump + Changes
parse the host string and extract the port

so that we can default to the SHARDCACHE_PORT_DEFAULT if none is present
in the host string
retry logic in get_multi and set_multi
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
implemented changes in the GET/OFFSET messages defined by protocol version 2

A shardcache node linking the new library will be able to revert to protocol v1
if responding to clients still implementing the protocol version 1

Clients build with the new library will be able to communicate only using protocol v2
(hence not compatible with older nodes)