Completely rewrote object data access to improve performance.

Completely rewrote object data access to improve performance.

According to the profiling that I was able to do we were spending a lot
of our time in the object decompression/delta application portions of
jgit when we were walking a large number of commit objects.  This is
what I feared, which was that our way-too-flexible stack of InputStreams
was simply costing us too much in overhead to be realistic.

So I've written pretty much all of that code and taking the approach
that core Git takes.  We allocate entire byte[] for data anytime we
need to work with something, rather than attempting to stream it from
an InputStream.  I've also pushed the object inflation code down as
close to the ByteWindow as possible, so that the byte window itself
can be offered up to the active Inflater as the input.  This actually
worked out well as it maintains  a nice clean abstraction between
the code that needs the decompressed data and the windows which hold
the compressed data.

So at this point once the data is in memory we are able to access it
without copying, except during decompression.  But if we are using a
mmapped region and Java won't let us get access to the underlying
byte[] (because its mapped MapMode.READ_ONLY) then we are forced to
copy the data into a temporary buffer before we can hand it over to
the deflate routine.

This version of the code shows a roughly a 10x speed improvement for
the case of walking along a chain of 50,000 commits (from the Mozilla
repository).

Unfortunately this version also contains a broken commit parser, an
untested but heavily modified tree tree parser, and a lightly tested
but also heavily modified binary delta apply routine.  More work
still needs to be done on those.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>