The header src/cc-compat.h defines portable format specifiers PRIuZ, PRIdZ, and PRIxZ. The original report highlighted the need to use these specifiers in examples/network/fetch.c.  For this commit, I checked all C source and header files not in deps/ and transitioned to the appropriate format specifier where appropriate.

Coverity complains about the git_rawobj ones because we use a loop in
which we keep remembering the old version, and we end up copying our
object as the base, so we want to have the data pointer be NULL.

`git_rebase_init` and `git_rebase_open` should take a
`git_rebase_options` and use it for future rebase operations on
that `rebase` object.

In `git_rebase_operation_current()`, indicate when a rebase has not
started (with `GIT_REBASE_NO_OPERATION`) rather than conflating that
with the first operation being in-progress.

This function is meant to simulate what git does in the reset command,
so we should include the reflog message in that.

The signature for the reflog is not something which changes
dynamically. Almost all uses will be NULL, since we want for the
repository's default identity to be used, making it noise.

In order to allow for changing the identity, we instead provide
git_repository_set_ident() and git_repository_ident() which allow a user
to override the choice of signature.

Provide git_indexwriter_init_for_operation for the common locking
pattern in merge, rebase, revert and cherry-pick.

Switch to a standard branch-switching pattern of a `SAFE` checkout,
then updating `HEAD`.

Don't require the branch to rebase, if given `NULL`, simply look up
`HEAD`.

Users may want to try to pay attention to the `exec` field on all
rebase operations.

Make it consistent between git_note_create() and git_note_remote() by
putting it after the repository.

Rename git_merge_head to git_annotated_commit, as it becomes used
in more operations than just merge.

Already cherry-picked commits should not be re-included.  If all changes
included in a commit exist in the upstream, then we should error with
GIT_EAPPLIED.

Commit the current patch of a rebase process.

`git_rebase_next` will apply the next patch (or cherry-pick)
operation, leaving the results checked out in the index / working
directory so that consumers can resolve any conflicts, as appropriate.

Abort an in-progress rebase and move the working directory and
repository back to the ORIG_HEAD state.

Introduce `git_rebase` to set up a rebase session that can
then be continued.  Immediately, only merge-type rebase is
supported.