Add const to some buffer functions
Make iterator APIs consistent with standards

The iterator APIs are not currently consistent with the parameter
ordering of the rest of the codebase.  This rearranges the order
of parameters, simplifies the naming of a number of functions, and
makes somewhat better use of macros internally to clean up the
iterator code.

This also expands the test coverage of iterator functionality,
making sure that case sensitive range-limited iteration works
correctly.
Retire spoolandsort iterator

Since the case sensitivity is moved into the respective iterators,
this removes the spoolandsort iterator code.
Add INCLUDE_TREES, DONT_AUTOEXPAND iterator flags

This standardizes iterator behavior across all three iterators
(index, tree, and working directory).  Previously the working
directory iterator behaved differently from the other two.

Each iterator can now operate in one of three modes:

1. *No tree results, auto expand trees* means that only non-
   tree items will be returned and when a tree/directory is
   encountered, we will automatically descend into it.
2. *Tree results, auto expand trees* means that results will
   be given for every item found, including trees, but you
   only need to call normal git_iterator_advance to yield
   every item (i.e. trees returned with pre-order iteration).
3. *Tree results, no auto expand* means that calling the
   normal git_iterator_advance when looking at a tree will
   not descend into the tree, but will skip over it to the
   next entry in the parent.

Previously, behavior 1 was the only option for index and tree
iterators, and behavior 3 was the only option for workdir.

The main public API implications of this are that the
`git_iterator_advance_into()` call is now valid for all
iterators, not just working directory iterators, and all the
existing uses of working directory iterators explicitly use
the GIT_ITERATOR_DONT_AUTOEXPAND (for now).

Interestingly, the majority of the implementation was in the
index iterator, since there are no tree entries there and now
have to fake them.  The tree and working directory iterators
only required small modifications.
Make tree iterator handle icase equivalence

There is a serious bug in the previous tree iterator implementation.
If case insensitivity resulted in member elements being equivalent
to one another, and those member elements were trees, then the
children of the colliding elements would be processed in sequence
instead of in a single flattened list.  This meant that the tree
iterator was not truly acting like a case-insensitive list.

This completely reworks the tree iterator to manage lists with
case insensitive equivalence classes and advance through the items
in a unified manner in a single sorted frame.

It is possible that at a future date we might want to update this
to separate the case insensitive and case sensitive tree iterators
so that the case sensitive one could be a minimal amount of code
and the insensitive one would always know what it needed to do
without checking flags.

But there would be so much shared code between the two, that I'm
not sure it that's a win.  For now, this gets what we need.

More tests are needed, though.
Add tests for case insensitive tree iterator

This adds a test case for ci tree iteration when there is a name
conflict.  This points out a behavior quirk in the current version
that I'd like to fix - namely, all tree entries get mapped to one
version of the case pattern in the ci code - i.e. even if you have
A/1.txt and a/2.txt, both will be reported as a/1.txt and a/2.txt
because we only copy the name of a file at a given frame once. It
would be nice to fix this, but I'm worried about how complex that
is if you get a/B/c/1.txt and A/b/C/2.txt.  It may require a walk
up the frames whenever you advance to the next item in a blended
equivalence class.
Use correct case path in icase tree iterator

If there are case-ambiguities in the path of a case insensitive
tree iterator, it will now rewrite the entire path when it gives
the path name to an entry, so a tree with "A/b/C/d.txt" and
"a/B/c/E.txt" will give the true full paths (instead of case-
folding them both to "A/B/C/d.txt" or "a/b/c/E.txt" or something
like that.
Fix tree iterator path for tree issue + cleanups

This fixes an off by one error for generating full paths for
tree entries in tree iterators when INCLUDE_TREES is set.  Also,
contains a bunch of small code cleanups with a couple of small
utility functions and macro changes to eliminate redundant code.
Fix tree iterator advance using wrong name compare

Tree iterator advance was moving forward without taking the
filemode of the entries into account, equating "a" and "a/".
This makes the tree entry comparison code more easily reusable
and fixes the problem.
handle small files in similarity metrics
Merge pull request #1407 from ethomson/tform_small_files

handle small files in similarity metrics
Stabilize order for equiv tree iterator entries

Given a group of case-insensitively equivalent tree iterator
entries, this ensures that the case-sensitively first trees will
be used as the representative items.  I.e. if you have conflicting
entries "A/B/x", "a/b/x", and "A/b/x", this change ensures that
the earliest entry "A/B/x" will be returned.  The actual choice
is not that important, but it is nice to have it stable and to
have it been either the first or last item, as opposed to a
random item from within the equivalent span.
Implemented push on the local transport
Merge pull request #1406 from cpthamilton/local_push

Implemented push on the local transport
Sorting function cleanup and MinGW fix

Clean up some sorting function stuff including fixing qsort_r
on MinGW, common function pointer type for comparison, and basic
insertion sort implementation (which we, regrettably, fall back
on for MinGW).
Merge pull request #1408 from arrbee/refactor-iterators

Refactor iterators
Advertise and support side-band-64k when calling receive-pack
Style: Reverse lhs and rhs of == comparisons
Merge pull request #1410 from phkelley/push_sideband

Advertise and support side-band-64k when calling receive-pack
MSVC: What could possibly be the size of a void*?