Fix the process of META lookups for HBase 0.95 and up.

There is no longer any -ROOT- region in 0.95 and up, so when we find
a /meta-region-server znode in ZK, we now set a flag to remember that
there is no -ROOT- region, and we treat the .META. region as the -ROOT-
region.
Send the proper "hello" message to HBase 0.95 and up.

Upon connecting to HBase we need to send a "hello" message, which
is now partly a protocol buffer.
Remove some unused helper code to create buffers.

We never need to use dynamic buffers as we can always produce a
good conservative estimate of how many bytes we need to serialize
an RPC.
Update the per-RPC header for HBase 0.95+.
Refactor how RPC objects know what RPC method they're for.

Introduce a new internal method to HBaseRpc, method(version), which
must return the RPC method name to invoke, given the HBase protocol
version of the server we're connected to.

Previously, all HBaseRpc instances had a `method' byte array in the
object that carried the name of the method to invoke (e.g. "get" or
"put").  Although the names were only created once (statics) this
still added one reference to each and every RPC object.

With HBase 0.95+ compatibility, many RPCs have changed their names
and thus it makes sense to standardize on an internal API that RPCs
must have to declare the name of the RPC method they should invoke
as a function of the HBase protocol version.
Compile Java code generated from protobuf files separately.

There is so much code in there that's a bit slow to compile,
even though javac is far from being a real compiler.  Since
the generated protobuf can be compiled on its own and is less
likely to change (as it would only change as a result of an
update made to one of the .proto files), building it on its
own allows subsequent incremental builds to stay just as fast
as they used to be.
Kill some trailing whitespaces.
Add a helper function to de-serialize Protocol Buffer VarInt32.

The header in each response is prefixed by a varint32 so we need a
method to read those.  This implementation is about 30% faster than
that in the Google protobuf library, and was proposed upstream:
https://code.google.com/p/protobuf/issues/detail?id=534
Add a semi-evil helper class to avoid copying byte arrays from protobufs.

Because the protobuf library unfortunately decided that to be really
safe one would always have to copy a byte[] out of a ByteString,
even though the majority of the time this is unnecessary after having
de-serialized a message from the wire.  One of the things AsyncHBase
watches out for is not only the memory footprint but also the rate at
which memory is allocated.  Without this trick, we have to create an
additional copy of every single byte array we obtain from protobufs.

HBase has even chosen to put some of the data outside of the protobufs
to avoid copying it, which is really a bummer IMO as it would have
been nicer to have everything in the RPC be protobuf'ed, instead of
having part of the payload be outside of the protobuf message as an
optimization.
De-serialize RPC responses from HBase 0.95+.
Add a helper function to de-serialize protocol buffers.
Handle META lookups with 0.95+.

Add basic code to de-serialize Get responses as well as
the RegionInfo they contain when doing META lookups.
Dedup byte arrays when deserializing KeyValues from 0.95+.
Make sure we have all the data we need before de-serializing.

Otherwise the protobuf library will complain because we're handing it a
buffer that contains a partial message.
Convert GetRequest to HBase 0.95+.
Convert AtomicIncrementRequest to HBase 0.95+.
Make the run target depend on the jar.
WIP: Convert scanners to HBase 0.95+.
XXX temporarily reject RPC responses with cell blocks.