diff: provide more context to the consumer of the callbacks

Update the callback to provide some information related to the file change being processed and the range of the hunk, when applicable.

Teach travis how to build the project.

The recent 64-bit Windows fixes changed the return code in
git_pkt_parse_line() so it wouldn't signal a short buffer, breaking
the network code. Bring it back.

Ignore pat leading slash

We were not following the git behavior for leading slashes
in path names when matching git ignores and git attribute
file patterns.  This should fix issue #638.

Memory pools and khash hashtables

This renamed `git_khash_str` to `git_strmap`, `git_hash_oid` to
`git_oidmap`, and deletes `git_hashtable` from the tree, plus
adds unit tests for `git_strmap`.

More Networking updates

This updates khash.h with some extra features (like error checking
on allocations, ability to use wrapped malloc, foreach calls, etc),
creates two high-level wrappers around khash: `git_khash_str` and
`git_khash_oid` for string-to-void-ptr and oid-to-void-ptr tables,
then converts all of the old usage of `git_hashtable` over to use
these new hashtables.

For `git_khash_str`, I've tried to create a set of macros that
yield an API not too unlike the old `git_hashtable` API.  Since
the oid hashtable is only used in one file, I haven't bother to
set up all those macros and just use the khash APIs directly for
now.

Adding a small stash of nodes with key conflicts has been
demonstrated to greatly increase the efficiency of a cuckoo
hashtable.  See:

  http://research.microsoft.com/pubs/73856/stash-full.9-30.pdf

for more details.

This removes the custom paged allocator from revwalk and
replaces it with a `git_pool`.

This converts the git attr related code (including ignores) and
the git diff related code (and implicitly the status code) to use
`git_pools` for storing strings.  This reduces the number of small
blocks allocated dramatically.

This adds a `git_pool` object that can do simple paged memory
allocation with free for the entire pool at once.  Using this,
you can replace many small allocations with large blocks that
can then cheaply be doled out in small pieces.  This is best
used when you plan to free the small blocks all at once - for
example, if they represent the parsed state from a file or data
stream that are either all kept or all discarded.

There are two real patterns of usage for `git_pools`: either
for "string" allocation, where the item size is a single byte
and you end up just packing the allocations in together, or for
"fixed size" allocation where you are allocating a large object
(e.g. a `git_oid`) and you generally just allocation single
objects that can be tightly packed.  Of course, you can use it
for other things, but those two cases are the easiest.

This limitation was a misparsing of the documentation.

This allows the caller to update an internal structure or update the
user output with the tips that were updated.

While in the area, only try to update the ref if the value is
different from its old one.

In the case that walk->one is NULL, we know that we have no positive
references, so we already know that the revwalk is over.

This allows us to give updates on how it's doing

Trying to send every single line immediately won't give us any speed
improvement and duplicates the code we need for other transports. Make
the git transport use the same buffer functions as HTTP.

This changes the git_remote_download() API, but the existing one is
silly, so you don't get to complain.

The new API allows to know how much data has been downloaded, how many
objects we expect in total and how many we've processed.

Code clean up, including fixing warnings on Windows 64-bit build

Fix git_repository_set_odb() refcount issue

git_repository_free() calls git_odb_free() if the owned odb is not null.

According to the doc, when setting a new odb through git_repository_set_odb() the caller has to take care of releasing the odb by himself.

Signed-off-by: schu <schu-github@schulog.org>

The code used to assume that there had to be data after the newline in
a tree cache extension entry. This isn't true for a childless
invalidated entry if it's the last one, as there won't be any children
nor a hash to take up space.

Adapt the off-by-one comparison to also work in this case. Fixes #633.

Index refcount issue

This fixes all the warnings on win64 except those in deps, which
come from the regex code.