Create a custom allocator for the `buf::oom` tests that will fail with
out-of-memory errors in predictable ways.  We were previously trying to
guess the way that various allocators on various platforms would fail
in a way such that `malloc`/`realloc` would return `NULL` (instead of
aborting the application, or appearing suspicious to various
instrumentation or static code analysis tools like valgrind.)

Introduce a fake `malloc` and `realloc` that will return `NULL` on
allocations requesting more than 100 bytes.  Otherwise, we proxy to the
default allocator.  (It's important to use the _default_ allocator, not
just call `malloc`, since the default allocator on Windows CI builds may
be the debugging C runtime allocators which would not be compatible with
a standard `malloc`.)

On a 32-bit Linux systems, the value large enough to make malloc
guarantee a failure is also large enough that valgrind considers it
"fishy".  Skip this test on those systems entirely.

On Linux (where we run valgrind) allocate a smaller buffer, but still an
insanely large size.  This will cause malloc to fail but will not cause
valgrind to report a likely error with a negative-sized malloc.

Keep the original buffer size on non-Linux platforms: this is
well-tested on them and changing it may be problematic.  On macOS, for
example, using the new size causes `malloc` to print a warning to
stderr.

Parse values up to and including `\377` (`0xff`) when unquoting.
Print octal values as an unsigned char when quoting, lest `printf`
think we're talking about negatives.

Introduce `git_buf_grow_by` to incrementally increase the size of a
`git_buf`, performing an overflow calculation on the growth.