This adds tests for diffs with submodules in them and (perhaps
unsurprisingly) requires further fixes to be made.  Specifically,
this fixes:

- when considering if a submodule is dirty in the workdir, it was
  being treated as dirty even if only the index was dirty.
- git_diff_patch_to_str (and git_diff_patch_print) were "printing"
  the headers for files (and submodules) that were unmodified or
  had no meaningful content.
- added comment to previous fix and removed unneeded parens.

This started out trying to look at the problems from issue #1425
and gradually grew to a broader set of fixes.  There are two core
things fixed here:

1. When you had an ignore like "/bin" which is rooted at the top
   of your tree, instead of immediately adding the "bin/" entry
   as an ignored item in the diff, we were returning all of the
   direct descendants of the directory as ignored items.  This
   changes things to immediately ignore the directory.  Note that
   this effects the behavior in test_status_ignore__subdirectories
   so that we no longer exactly match core gits ignore behavior,
   but the new behavior probably makes more sense (i.e. we now
   will include an ignored directory inside an untracked directory
   that we previously would have left off).
2. When a submodule only contained working directory changes, the
   diff code was always considering it unmodified which was just
   an outright bug. The HEAD SHA of the submodule matches the SHA
   in the parent repo index, and since the SHAs matches, the diff
   code was overwriting the actual status with UNMODIFIED.

These fixes broke existing tests test_diff_workdir__submodules and
test_status_ignore__subdirectories but looking it over, I actually
think the new results are correct and the old results were wrong.
@nulltoken had actually commented on the subdirectory ignore issue
previously.

I also included in the tests some debugging versions of the
shared iteration callback routines that print status or diff
information.  These aren't used actively in the tests, but can be
quickly swapped in to test code to give a better picture of what
is being scanned in some of the complex test scenarios.

This option has been sitting unimplemented for a while, so I
finally went through and implemented it along with some tests.

As part of this, I improved the implementation of
GIT_DIFF_IGNORE_SUBMODULES so it be more diligent about avoiding
extra work and about leaving off delta records for submodules to
the greatest extent possible (though it may include them still
if you are request TYPECHANGE records).

This implements working versions of GIT_DIFF_RECURSE_IGNORED_DIRS
and GIT_STATUS_OPT_RECURSE_IGNORED_DIRS along with some tests for
the newly available behaviors.  This is not turned on by default
for status, but can be accessed via the options to the extended
version of the command.

1. Fix sort order problem with submodules where "mod" was sorting
   after "mod-plus" because they were being sorted as "mod/" and
   "mod-plus/".  This involved pushing the "contains a .git entry"
   test significantly lower in the stack.
2. Reinstate behavior that a directory which contains a .git entry
   will be treated as a submodule during iteration even if it is
   not yet added to the .gitmodules.
3. Now that any directory containing .git is reported as submodule,
   we have to be more careful checking for GIT_EEXISTS when we
   do a submodule lookup, because that is the error code that is
   returned by git_submodule_lookup when you try to look up a
   directory containing .git that has no record in gitmodules or
   the index.

Refactor iterators

Previously, 0 meant default. This is problematic, as asking for 0
context lines is a valid thing to do.

Change GIT_DIFF_OPTIONS_INIT to default to three and stop treating 0
as a magic value. In case no options are provided, make sure the
options in the diff object default to 3.

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.

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

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.