Upgrade to Netty 3.4.2.

Change-Id: I7b477eafa76f3a183075403fcf334b87bc09553f
Update NEWS and set version to 1.3.0-SNAPSHOT.

Change-Id: I59f9ccc1ea743e2b690c5689e94d5d7c4035892d
Add a dependency on Google's Guava library.

Google Guava's code quality far exceeds the requirements to be
used as a dependency in asynchbase.  The first use of Guava will
be their concurrent in-memory cache to implement increment coalescing.

Change-Id: I661cc6a31c4c7ce336356ffa74289ad37e6551f6
Update to suasync 1.2.0.

Change-Id: Ie9a33c12399a1d007d99b1b95ac3324546acaae7
Atomic increment coalescing.

Add a new method, `bufferAtomicIncrement', to allow client-side
coalescing of atomic increments.  This closes #20.

In high-throughput user-facing applications that do a lot of counter
increments with a reasonable working set, this can significantly reduce
the number of RPCs and write load on HBase.  For example, at StumbleUpon
we have user-facing application servers that increment various counters
in HBase to keep track of user activity and URL activity, and increment
coalescing is able to reduce 30000 increments/s down to 2000 RPC/s,
a 15x reduction in write load.

Change-Id: I76e427430258d4281c2d4342ff3469d39a8f71a0
Add an integration test for increment coalescing.

Run it with:
  $ make run CLASS=TestIncrementCoalescing JVM_ARGS='-Xmx2g -Xms2g' \
      ARGS='mytable myfamily'

Sample expected output:
  TestIncrementCoalescing: Deleting existing rows...
  TestIncrementCoalescing: Done deleting existing rows.
  TestIncrementCoalescing: 16000000 increments in 6045ms = 2646815/s
  TestIncrementCoalescing: Increments coalesced: 16009268
  TestIncrementCoalescing: Increments sent to HBase: 9239
  TestIncrementCoalescing:   due to cache evictions: 0
  TestIncrementCoalescing: Reading all counters back from HBase and checking values...
  TestIncrementCoalescing: Done checking counter values.

Change-Id: I8a3b015d5fb767c140513ee24d00493ef94da3ae
Keep track of usage statistics.

Add counters to keep track of various types of activities (RPCs sent,
connections created, etc.) and provide an API to get a snapshot of the
stats.  All counters are using the JSR 166e sharded counter in order
to minimize the overhead of stats collection.

In practice all application servers that use asynchbase need to collect
these stats anyway to expose them to the monitoring system, so we may
as well have the stats built into the client.  At the moment there is
no mechanism to disable stats collection.

Change-Id: I3913b67de69cf32cab01f8aecee392d743f33e62
Clean up any stale temporary file if we already have the right file.

Change-Id: I388d7f8c64f4f8316334a920e78330e311a40315
Add a CAS (Compare And Set) API.

Based on a patch by Guo Sijie.  This closes #22.

Change-Id: I2ce17ccba974292ad69ffc4a99060b8f08252953
Allow passing a time range to a scanner.

Based on a patch by Michael Rose.  This closes #24.

Change-Id: I39e2947ecb0d6003db1248b5997f0024a09979b3
Clean up the test .class files too.

Change-Id: I5d73bb7cc606f86c86e5190023db4cffb4ed91b1
Add a helper function to pretty-print an array of byte arrays.

Change-Id: I5aea748cf36d958262c383930d433e345478053c
Enhance a toString helper for RPCs to also support values.

Change-Id: Ib7833db9d4469e307384e931d857498aa632a6d0
Allow PutRequest to affect multiple columns in a row.

This was required despite automatic batching of edits so as to
allow atomic CAS operations on multiple cells within a row.

Change-Id: I70466ccbbfe0fb4ee1b70d58f899111650a4902b