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_.

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

Since we now always build the library with cdecl calling conventions,
our callbacks should be decorated as such so that users will not be able
to provide callbacks defined with other calling conventions.

The `GIT_CALLBACK` macro will inject the `__cdecl` attribute as
appropriate.

git_object_t is the future; update the public API to use it.  This will
also ensure that we can build our tests which make use of the old API
without modification (and without compiler warnings).

The streaming read functionality should provide the length and the type
of the object, like the normal read functionality does.

When writing an object, we calculate its OID and see if it exists in the
object database.  If it does, we need to freshen the file that contains
it.

As refdb and odb backends can be allocated by client code, libgit2
can’t know whether an alternative memory allocator was used, and thus
should not try to call `git__free` on those objects.

Instead, odb and refdb backend implementations must always provide
their own `free` functions to ensure memory gets freed correctly.

Restricting files to size_t is a silly limitation. The loose backend
writes to a file directly, so there is no issue in using 63 bits for the
size.

We still assume that the header is going to fit in 64 bytes, which does
mean quite a bit smaller files due to the run-length encoding, but it's
still a much larger size than you would want Git to handle.