[Doc] Update URL to git2-rs

remote: Rename git_remote_completion_type to _t

odb: provide a free function for custom backends

This reverts commit 1fe3fa5e.

For consistency with other "type" enums, rename
git_remote_completion_type to git_remote_completion_t.

Have git_branch_lookup accept GIT_BRANCH_ALL

Custom backends can allocate memory when reading objects and providing
them to libgit2.  However, if an error occurs in the custom backend
after the memory has been allocated for the custom object but before
it's returned to libgit2, the custom backend has no way to free that
memory and it must be leaked.

Provide a free function that corresponds to the alloc function so that
custom backends have an opportunity to free memory before they return an
error.

The `git_odb_backend_malloc` name is a system function that is provided
for custom ODB backends and allows them to allocate memory for an ODB
object in the read callback.  This is important so that libgit2 can
later free the memory used by an ODB object that was read from the
custom backend.

However, the name _suggests_ that it actually allocates a
`git_odb_backend`.  It does not; rename it to make it clear that it
actually allocates backend _data_.

Rename git_transfer_progress to git_indexer_progress

Safely deprecate `git_push_transfer_progress`, forwarding it to the new
`git_push_transfer_progress_cb` name.

The `git_push_transfer_progress` is a callback and as such should be
suffixed with `_cb` for consistency.  Rename
`git_push_transfer_progress` to `git_push_transfer_progress_cb`.

Safely deprecate `git_transfer_progress` and `git_transfer_progress_cb`
types, forwarding them to the new `git_indexer_progress` and
`git_indexer_progress_cb`.

Update internal usage of `git_transfer_progress` to
`git_indexer_progreses`.

The name `git_transfer_progress` does not reflect its true purpose.

It suggests that it's progress for a non-existence `git_transfer`
object, and is used for indexing callbacks more broadly than just
during transfers.

Rename `git_transfer_progress` to `git_indexer_progress`.

High-level map APIs

refdb_fs: fix loose/packed refs lookup racing with repacks

Allocator restructuring

cache: fix misnaming of `git_cache_free`

examples: produce single cgit2 binary

Functions that free a structure's contents but not the structure
itself shall be named `dispose` in the libgit2 project, but the
function `git_cache_free` does not follow this naming pattern.

Fix this by renaming it to `git_cache_dispose` and adjusting all
callers to make use of the new name.

In commit 6e0dfc6f (Make stdalloc__reallocarray call
stdalloc__realloc, 2019-02-16), we have changed the stdalloc
allocator to reuse `stdalloc__realloc` to implement
`stdalloc__reallocarray`. This commit is making the same change
for the Windows-specific crtdbg allocator to avoid code
duplication.

The Windows-specific crtdbg allocator is currently mixed into the
crtdbg stacktracing compilation unit, making it harder to find
than necessary. Extract it and move it into the new "allocators/"
subdirectory to improve discoverability.

This change means that the crtdbg compilation unit is now
compiled unconditionally, whereas it has previously only been
compiled on Windows platforms. Thus we now have additional guards
around the code so that it will only be compiled if
GIT_MSVC_CRTDBG is defined. This also allows us to move over the
fallback-implementation of `git_win32_crtdbg_init_allocator` into
the same compilation unit.

Right now, our two allocator implementations are scattered around
the tree in "stdalloc.h" and "win32/w32_crtdbg_stacktrace.h".
Start grouping them together in a single directory "allocators/",
similar to how e.g. our streams are organized.

Remove public 'inttypes.h' header

Remove an `inttypes.h` header that is too large in scope, and far too
public.

For Visual Studio 2012 and earlier (ie, `_MSC_VER < 1800`), we do need
to include `stdint.h` in our public headers, for types like `uint32_t`.

Internally, we also need to define `PRId64` as a printf formatting
string when it is not available.

Prevent reading out of bounds memory

Previously, we would fail to correctly truncate the source buffer
if the source has more than one line and ends with a non-newline
character. In the following call, we thus truncate the source
string in the middle of the second line. Without the bug fixed,
we would successfully apply the patch to the source and return
success. With the overflow being fixed, we should return an
error now.

When parsing the patch image from a string, we split the string
by newlines to get a line-based view of it. To split, we use
`memchr` on the buffer and limit the buffer length by the
original length provided by the caller. This works just fine for
the first line, but for every subsequent line we need to actually
subtract the amount of bytes that we have already read.

The above issue can be easily triggered by having a source buffer
with at least two lines, where the second line does _not_ end in
a newline. Given a string "foo\nb", we have an original length of
five bytes. After having extracted the first line, we will point
to 'b' and again try to `memchr(p, '\n', 5)`, resulting in an
out-of-bounds read of four bytes.

Fix the issue by correctly subtracting the amount of bytes
already read.

Fix a memory leak in odb_otype_fast()

This change frees a copy of a cached object in odb_otype_fast().

Make stdalloc__reallocarray call stdalloc__realloc

Remove `git_time_monotonic`

Fix a _very_ improbable memory leak in git_odb_new()