Have flush() take into account buffered increments in its return value.

Calling client.flush().join() would correctly flush all buffered atomic
increments, but would return too early, potentially before all the RPCs
doing increments have completed. This was due to the fact that when the
increment buffer gets flushed,  the RPCs sent out weren't tied together
to the Deferred returned.

Getting access to the Deferreds of the atomic increments sent out as the
result of a flush() is hard, because these Deferreds are created from a
callback invoked by Guava upon clearing the increment_buffer.  Instead,
to workaround this problem, call sync() on the RegionClients, a method
introduced to provide a semantic similar to Linux's sync(2) system call.

This closes #38.
Flush buffered increments only from one thread at a time.

Concurrent flushes introduce subtle issues, such as in the
following scenario:
  1. Main thread calls client.flush().
  2. Client calls increment_buffer.invalidateAll().
  3. Guava executes clear() on the first segment of the cache.
  4. Guava locks first segment, removes all entries.
  5. The timer thread makes its periodic call to flush().
  6. Steps 2-3 happen in the timer thread, followed by:
  7. Guava attempts to lock the first segment, gets blocked.
  8. Main thread releases the lock on the first segment.
  9. Main thread processes eviction callbacks for entries removed from
     first segment.
 10. Timer thread grabs lock on first segment, finds it empty.
 11. Main thread is still busy with eviction callbacks.
 12. Timer thread locks second segment, starts clearing it.
 13. Main thread will never see the buffered increments cleared by the
     timer thread, and the Deferred returned from client.flush() may
     not include the increments handled by the timer thread if the
     timer thread doesn't put them fast enough in the rpcs_inflight
     map, which easily happened during stress testing.

By locking around the call to increment_buffer.invalidateAll(), in the
scenario above, the main thread will either see all entries in the map
or none, depending on which thread manages to execute its flush() first.
This is better because this way the second call to flush() is guaranteed
to find the flushed RPCs in rpcs_inflight.
Upgrade to suasync 1.3.1 to avoid restrictive limit on callback chains.
Fix and enhance increment coalescing.

This closes #41, whereby a too large number of increments that pile up
for a given counter could cause a Deferred chain to blow up.  We now
guarantee that this will not happen by keeping track of how many times
each counter gets incremented, and pro-actively flushing those that
reach the limit on the length of the Deferred chain.  This has a nice
side effect that the *really* busy counters will get flushed more often.
This tracking is done without any extra locking or synchronization and
only costs an extra 32 bits of memory per coalesced counter.

This enhances increment coalescing to support negative increment values
as well as values greater than Short.MAX_VALUE (65535).  There is still
a limit on how big the values can be, but the limit is much higher now
(2^48 - 1) and values greater than that are still gracefully handled.

The code is also more robust now in face of overflows / underflows, as
the previous implementation had one potential race condition, which
although it would have been incredibly rare, was still possible anyway.
We now explicitly check for overflows / underflows before we CAS the
value, so that when an overflow / underflow condition is detected we
abort the update gracefully and let the caller know so they can flush
the counter and create a new one to start coalescing again.

This change also adds extra integration tests for various corner cases.
Save about 1s on integration tests.