We currently first look in the loose object dir and then in the packs
for objects. When performing operations on recent history this has a
higher likelihood of hitting, but when we deal with operations which
look further back into the past, we start spending a large amount of
time getting ENOTENT from `access`.

Reversing the priorities means that long-running operations can get to
their objects faster, as we can look at the index data we have in memory
(or rather mapped) to figure out whether we have an object, which is
faster than going out to the filesystem.

The packed backend already implements an optimistic read algorithm by
first looking at the packs we know about and only going out to disk to
referesh if the object is not found which means that in the case where
we do have the object (which will be in the majority for anything that
traverses the graph) we can avoid going to to disk entirely to determine
whether an object exists.

Operations which look at recent history may take a slight impact, but
these would be operations which look a lot less at object and thus take
less time regardless.

Centralizing all IO buffer size values

Stash apply

Allow the baseline to be specified as an index, so that users
need not write their index to a tree just to checkout with that
as the baseline.

Adjusting stream buffer size to 64KB

64K is optimal buffer size per https://technet.microsoft.com/en-us/library/cc938632.aspx

Android build doesn't need deps/regex

Ensure frameworks are mentioned in libgit2.pc

When building on Mac OS X, the `CoreFoundation` and `Security` frameworks where missing from `Libs.private` in the generated `libgit2.pc` file.

deps/regex was included in Android build because Android NDK 4 has
a packaging bug and doesn't have the regular expression functions defined
in its libc.so. The bug has been fixed in subsequent Android NDK releases.

If it is still necessary to work around the bug in Android NDK 4, we
should consider to use an option like ANDROID_NDK_RELEASE or
ANDROID_NDK_RELEASE_NUM.

Configuration changes for handling multiple of the same sections

Case insensitive checkout improvements

If a multivar exists within two sections (of the same name)
then they should both be updated in a `set_multivar`.  Ensure
that this is the case.

When writing a configuration file, we want to take a lock on the
new file (eg, `config.lock`) before opening the configuration file
(`config`) for reading so that we can prevent somebody from changing
the contents underneath us.

Add a test that exposes a bug in config_write.
It is valid to have multiple separate headers for the same config section, but
config_write will exit after finding the first matching section in certain
situations.
This test proves that config_write will duplicate a variable that already
exists instead of overwriting it if the variable is defined under a duplicate
section header.

When updating a configuration file, we want to copy the old data
from the file to preserve comments and funny whitespace, instead
of writing it in some "canonical" format.  Thus, we keep a
pointer to the start of the line and the line length to preserve
these things we don't care to rewrite.

Previously we would try to be clever when writing the configuration
file and try to stop parsing (and simply copy the rest of the old
file) when we either found the value we were trying to write,
or when we left the section that value was in, the assumption being
that there was no more work to do.

Regrettably, you can have another section with the same name later
in the file, and we must cope with that gracefully, thus we read the
whole file in order to write a new file.

Now, writing a file looks even more than reading.  Pull the config
parsing out into its own function that can be used by both reading
and writing the configuration.

On Mac OS, `realpath` is deficient in determining the actual filename
on-disk as it will simply provide the string you gave it if that file
exists, instead of returning the filename as it exists.  Instead we
must read the directory entries for the parent directory to get the
canonical filename.