The `git_walk_objects` structure is currently only being used inside of
the pack-objects.c file, but being declared in its header. This has
actually been the case since its inception in 04a36feff (pack-objects:
fill a packbuilder from a walk, 2014-10-11) and has never really
changed.

Move the struct declaration into pack-objects.c to improve code
encapsulation.

use consistent names for the #include / #define header guard pattern.

After 1cd65991, we were passing a pointer to an `unsigned long` to
a function that now expected a pointer to a `size_t`.  These types
differ on 64-bit Windows, which means that we trash the stack.

Use `size_t`s in the packbuilder to avoid this.

This is useful to send to the client while we're performing the work.

The reporting function has a force parameter which makes sure that we
do send out the message of 100% completed, even if this comes before the
next udpate window.

Most use-cases for the object packer communicate in terms of commits
which each side has. We already have an object to specify this
relationship between commits, namely git_revwalk.

By knowing which commits we want to pack and which the other side
already has, we can perform similar optimisations to git, by marking
each tree as interesting or uninteresting only once, and not sending
those trees which we know the other side has.

This adds the basics of progress reporting during push. While progress
for all aspects of a push operation are not reported with this change,
it lays the foundation to add these later. Push progress reporting
can be improved in the future - and consumers of the API should
just get more accurate information at that point.

The main areas where this is lacking are:

1) packbuilding progress: does not report progress during deltafication,
   as this involves coordinating progress from multiple threads.

2) network progress: reports progress as objects and bytes are going
   to be written to the subtransport (instead of as client gets
   confirmation that they have been received by the server) and leaves
   out some of the bytes that are transfered as part of the push protocol.
   Basically, this reports the pack bytes that are written to the
   subtransport. It does not report the bytes sent on the wire that
   are received by the server. This should be a good estimate of
   progress (and an improvement over no progress).