Implement opts interface for global/system file search paths

Get rid of some dead code, tighten things up a bit, and fix a bug
with core::env test.

This switches the APIs for setting and getting the global/system
search paths from using git_strarray to using a simple string with
GIT_PATH_LIST_SEPARATOR delimited paths, just as the environment
PATH variable would contain.  This makes it simpler to get and set
the value.

I also added code to expand "$PATH" when setting a new value to
embed the old value of the path.  This means that I no longer
require separate actions to PREPEND to the value.

Several warnings detected by static code analyzer fixed

Failing config related test

MSVC cmake improvements

Implicit type conversion argument of function to size_t type
Suspicious sequence of types castings: size_t -> int -> size_t
Consider reviewing the expression of the 'A = B == C' kind. The expression is calculated as following: 'A = (B == C)'
Unsigned type is never < 0

(see http://public.kitware.com/Bug/view.php?id=11240)

This is useful when linking libgit2 statically, as the setting must match the linking program's one.

The goal of this work is to expose the search logic for "global",
"system", and "xdg" files through the git_libgit2_opts() interface.

Behind the scenes, I changed the logic for finding files to have a
notion of a git_strarray that represents a search path and to store
a separate search path for each of the three tiers of config file.
For each tier, I implemented a function to initialize it to default
values (generally based on environment variables), and then general
interfaces to get it, set it, reset it, and prepend new directories
to it.

Next, I exposed these interfaces through the git_libgit2_opts
interface, reusing the GIT_CONFIG_LEVEL_SYSTEM, etc., constants
for the user to control which search path they were modifying.
There are alternative designs for the opts interface / argument
ordering, so I'm putting this phase out for discussion.

Additionally, I ended up doing a little bit of clean up regarding
attr.h and attr_file.h, adding a new attrcache.h so the other two
files wouldn't have to be included in so many places.

Further tree_iterator refactoring

Fix various build warnings

This fixes various build warnings on Mac and Windows (64-bit).

This adds a git_pool_freelist_item struct that makes it a little
easier to follow what's going on with the pool free list block
management code.  It is functionally neutral.

This fixes a number of issues identified by valgrind - mostly
missed free calls.  Inside valgrind, mmap() may fail which causes
some of the diff tests to fail.  This adds a fallback code path
to diff_output.c:get_workdir_content() where is the mmap() fails
the code will now try to read the file data directly into allocated
memory (which is what it would do if the data needed to be filtered
anyhow).

This updates the tree iterator internals to be more efficient.

The tree_iterator_entry objects are now kept as pointers that are
allocated from a git_pool, so that we may use git__tsort_r for
sorting (which is better than qsort, given that the tree is
likely mostly ordered already).

Those tree_iterator_entry objects now keep direct pointers to the
data they refer to instead of keeping indirect index values.  This
simplifies a lot of the data structure traversal code.

This also adds bsearch to find the start item position for range-
limited tree iterators, and is more explicit about using
git_path_cmp instead of reimplementing it.  The git_path_cmp
changed a bit to make it easier for tree_iterators to use it (but
it was barely being used previously, so not a big deal).

This adds a git_pool_free_array function that efficiently frees a
list of pool allocated pointers (which the tree_iterator keeps).
Also, added new tests for the git_pool free list functionality
that was not previously being tested (or used).

Fix workdir iterator bugs

This fixes two bugs with the workdir iterator depth check: first
that the depth was not being decremented and second that empty
directories were counting against the depth even though a frame
was not being created for them.

This also fixes a bug with the ENOTFOUND return code for workdir
iterators when you attempt to advance_into an empty directory.
Actually, that works correctly, but it was incorrectly being
propogated into regular advance() calls in some circumstances.

Added new tests for the above that create a huge hierarchy on
the fly and try using the workdir iterator to traverse it.

Advertise and support side-band-64k when calling receive-pack

Refactor iterators

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).

Implemented push on the local transport

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.

handle small files in similarity metrics

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.

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.

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.

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.

Can't perform diff with no context lines

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.

Passing NULL is non-sensical. The error message leaves to be desired,
though, as it leaks internal implementation details. Catch it at the
`git_config_set_string` level and set an appropriate error message.

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.