Quiet down a warning from MSVC about how we're potentially losing data.
Ensure that we're within a uint16_t before we do.

Move to the `git_error` name in the internal API for error-related
functions.

Use the new object_type enumeration names within the codebase.

Instead of using the `khiter_t`, `git_strmap_iter` and `khint_t` types,
simply use `size_t` instead. This decouples code from the khash stuff
and makes it possible to move the khash includes into the implementation
files.

The `parse_mode` option uses an open-coded octal number parser. The
parser is quite naive in that it simply parses until hitting a character
that is not in the accepted range of '0' - '7', completely ignoring the
fact that we can at most accept a 16 bit unsigned integer as filemode.
If the filemode is bigger than UINT16_MAX, it will thus overflow and
provide an invalid filemode for the object entry.

Fix the issue by using `git__strntol32` instead and doing a bounds
check. As this function already handles overflows, it neatly solves the
problem.

Note that previously, `parse_mode` was also skipping the character
immediately after the filemode. In proper trees, this should be a simple
space, but in fact the parser accepted any character and simply skipped
over it. As a consequence of using `git__strntol32`, we now need to an
explicit check for a trailing whitespace after having parsed the
filemode. Because of the newly introduced error message, the test
object::tree::parse::mode_doesnt_cause_oob_read needs adjustment to its
error message check, which in fact is a good thing as it demonstrates
that we now fail looking for the whitespace immediately following the
filemode.

Add a test that shows that we will fail to parse such invalid filemodes
now.

When parsing a tree entry's mode, we will eagerly parse until we hit a
character that is not in the accepted set of octal digits '0' - '7'. If
the provided buffer is not a NUL terminated one, we may thus read
out-of-bounds.

Fix the issue by passing the buffer length to `parse_mode` and paying
attention to it. Note that this is not a vulnerability in our usual code
paths, as all object data read from the ODB is NUL terminated.

We have two similar functions, `git_treebuilder_insert` and `append_entry` which
are used in different codepaths as part of creating a new tree. The former
learnt to check for object existence under strict object creation, but the
latter did not.

This allowed the creation of a tree from an unowned index to bypass some of the
checks and create a tree pointing to a nonexistent object.

Extract a single function which performs these checks and call it from both
codepaths. In `append_entry` we still do not validate when asked not to, as this
is data which is already in the tree and we want to allow users to deal with
repositories which already have some invalid data.

tree: accept null ids in existing trees when updating

When we add entries to a treebuilder we validate them. But we validate even
those that we're adding because they exist in the base tree. This disables
using the normal mechanisms on these trees, even to fix them.

Keep track of whether the entry we're appending comes from an existing tree and
bypass the name and id validation if it's from existing data.