Fixes a regression from #4092. This is a crash on 32-bit and I assume that
it doesn't do the right thing on 64-bit either. MSVC emits a warning for this,
but of course, it's easy to get lost among all of the similar 'possible loss
of data' warnings.

Improve clar messages

Provide more detailed messages when conditions pass or fail
unexpectedly.  In particular, this provides the error messages when a
test fails with a different error code than was expected.

`snprintf` requires a _format_ but does not require _arguments_ to the
format.  eg: `snprintf(buf, 42, "hi")` is perfectly legal.  Expand the
macro to match.

Without this, `p_sprintf(buf, 42, "hi")` errors with:

```
error: expected expression
                p_snprintf(msg, 42, "hi");
                ^
src/unix/posix.h:53:34: note: expanded from macro 'p_snprintf'
                                 ^
/usr/include/secure/_stdio.h:57:73: note: expanded from macro 'snprintf'
  __builtin___snprintf_chk (str, len, 0, __darwin_obsz(str),
__VA_ARGS__)
```

khash cleanups

refdb: catch additional per-worktree refs

Minor comment fix

The upstream git.git project currently identifies all references inside
of `refs/bisect/` as well as `HEAD` as per-worktree references. This is
already incorrect and is currently being fixed by an in-flight topic
[1]. The new behavior will be to match all pseudo-references outside of
the `refs/` hierarchy as well as `refs/bisect/`.

Our current behavior is to mark a selection of pseudo-references as
per-worktree, only. This matches more pseudo-references than current
git, but forgets about `refs/bisect/`. Adjust behavior to match the
in-flight topic, that is classify the following references as
per-worktree:

- everything outside of `refs/`
- everything inside of `refs/bisect/`

[1]: <20170213152011.12050-1-pclouds@gmail.com>

Signature cleanups

When extracting a commit's signature, we first free the object and only
afterwards put its signature contents into the result buffer. This works
in most cases - the free'd object will normally be cached anyway, so we
only end up decrementing its reference count without actually freeing
its contents. But in some more exotic setups, where caching is disabled,
this can definitly be a problem, as we might be the only instance
currently holding a reference to this object.

Fix this issue by first extracting the contents and freeing the object
afterwards only.

The functions `git_commit_header_field` and
`git_commit_extract_signature` both receive buffers used to hand back
the results to the user. While these functions called `git_buf_sanitize`
on these buffers, this is not the right thing to do, as it will simply
initialize or zero-terminate passed buffers. As we want to overwrite
contents, we instead have to call `git_buf_clear` to completely reset
them.

Changes to provide option to turn off/on ofs_delta

When `git_buf_sanitize` gets called, it converts a buffer with NULL
content to be correctly initialized. This is done by pointing it to
`git_buf__initbuf`. While the method's documentation states this
clearly, it may also lead to the conclusion that it will do the same to
buffers which do _not_ have NULL contents.

Clarify behavior when passing a buffer with non-NULL contents, where
`git_buf_sanitize` will ensure that the contents are `\0`-terminated.

Worktree implementation