cmake: use project-relative binary and source directories

Due to our split of CMake files into multiple modules, we had to replace
some uses of the `${CMAKE_CURRENT_SOURCE_DIR}` and
`${CMAKE_CURRENT_BINARY_DIR}` variables and replace them with
`${CMAKE_SOURCE_DIR}` and `${CMAKE_BINARY_DIR}`. This enabled us to
still be able to refer to top-level files when defining build
instructions inside of a subdirectory.

When replacing all variables, it was assumed that the absolute set of
variables is always relative to the current project. But in fact, this
is not the case, as these variables always point to the source and
binary directory as given by the top-levl project. So the change
actually broke the ability to include libgit2 directly as a subproject,
as source files cannot be found anymore.

Fix this by instead using project-specific source and binary directories
with `${libgit2_SOURCE_DIR}` and `${libgit2_BINARY_DIR}`.

Fix compilation for CMake versions 3.0.x where x >= 1

Apparently policy CMP0015 was added in CMake 3.1. With CMake 3.0.2,
the build was failing with

    CMake Error at CMakeLists.txt:18 (CMAKE_POLICY):
      Policy "CMP0051" is not known to this version of CMake.

This patch makes it work.

cmake: use static dependencies when building static libgit2

cmake: fix linking in Xcode with object libraries only

transports: smart: fix memory leak when skipping symbolic refs

tests: checkout::tree: verify status entrycount changes on chmod

CMake is unable to generate a correct Xcode project when trying to link
libraries with only object libraries as its input. As our new build
infrastructure makes heavy use of object libraries now, this affects our
libgit2 library target, as well, leading to linking errors.

Fix the issue by adding a dummy file to the libgit2 objects. As we
always have the "features.h" header ready which contains defines only,
we can simply link it into the resulting library without any effect
whatsoever. This fixes building with Xcode.

While we verify that we have no mode changes after calling
`git_checkout_tree`, we do not verify that the `p_chmod` calls actually
resulted in a changed entry. While we should assume that this works due
to separate tests for the status list, we should test for the change
being listed to avoid programming errors in the test.

There are multiple locations where we have the same code to check
whether the count of status list entries of a repository matches an
expected number. Extract that into a common function.

Checkout typechange-only deltas

When we setup the revision walk for negotiating references with a
remote, we iterate over all references, ignoring tags and symbolic
references. While skipping over symbolic references, we forget to free
the looked up reference, resulting in a memory leak when the next
iteration simply overwrites the variable.

Fix that issue by freeing the reference at the beginning of each
iteration and collapsing return paths for error and success.

Plug some leaks in curl's proxy handling

Test that we can successfully force checkout a target when the file
contents are identical, but the mode has changed.

On Windows, we do not support file mode changes, so do not test
for type changes between the disk and tree being checked out.

We could have false positives since the on-disk file can only have
an (effective) mode of 0100644 since NTFS does not support executable
files.  If the tree being checked out did have an executable file,
we would erroneously decide that the file on disk had been changed.

Fix Issue #4047 Check return codes and free objects

travis: add custom apt sources

remote: add typedef to normalize push_update_reference callback

refs: do not use peeled OID if peeling to a tag

Move back to Travis's VM infrastructure for efficiency.

When performing a forced checkout, treat files as modified when the
workdir or the index is identical except for the mode.  This ensures
that force checkout will update the mode to the target.  (Apply this
check for regular files only, if one of the items was a file and the
other was another type of item then this would be a typechange and
handled independently.)

Very many callbacks in libgit2 have some sort of typedef to normalize the name at git_<name_of_operation>_cb. Add a typedef for push_update_references in the remote so the name follows the same conventions.

Document that a commit is not a descendant of itself

Use SOCK_CLOEXEC when creating sockets

If a reference stored in a packed-refs file does not directly point to a
commit, tree or blob, the packed-refs file will also will include a
fully-peeled OID pointing to the first underlying object of that type.
If we try to peel a reference to an object, we will use that peeled OID
to speed up resolving the object.

As a reference for an annotated tag does not directly point to a commit,
tree or blob but instead to the tag object, the packed-refs file will
have an accomodating fully-peeled OID pointing to the object referenced
by that tag. When we use the fully-peeled OID pointing to the referenced
object when peeling, we obviously cannot peel that to the tag anymore.

Fix this issue by not using the fully-peeled OID whenever we want to
peel to a tag. Note that this does not include the case where we want to
resolve to _any_ object type. Existing code may make use from the fact
that we resolve those to commit objects instead of tag objects, even
though that behaviour is inconsistent between packed and loose
references. Furthermore, some tests of ours make the assumption that we
in fact resolve those references to a commit.

Static linking for bundled deps

The block in the script installs the packages if we're _not_ on Precise. This
was dropped in c17c3f8a ("travis: drop support for Ubuntu Precise") in error.