Handle tombstones returned by riak java client.

This change filters out tombstones return by client, how
this happens is dependent on whether HTTP or PBs are used.

In the HTTP case, tombstones are always returned.

In the PBs case, tombstones are only return when
ReturnDeletedVClock is true.

The high-level riak-java-client filters the tombstones
out in FetchObject, but not the RawClient, making
the behaviour appear the same reguardless of protocol.

As scaliak uses the RawClient, there is no way a
consumer of scaliak can control whether tombstones
are returned (for HTTP). This leads to a bad situation
in ScaliakConverter where you are presented with an
empty string for the deleted item and no way to handle
it.

This change matches the riak-java-client behaviour
of filtering tombstones based upon ReturnDeletedVClock.
The defaults chosen filter tombstones by default, they
will be returned, if and only if, ReturnDeletetedVClock
is set to true.

See https://github.com/basho/riak-java-client/blob/master/src/main/java/com/basho/riak/client/operations/FetchObject.java#L110-L130
for java client behaviour.

See https://github.com/basho/riak-java-client/issues/213
for related case against java client.
Merge pull request #19 from markhibberd/tombstones

Handle tombstones returned by riak java client.
Bump lift json version for JNull => JNothing fix