Let `git_path_find_dir` simply take a `git_buf` that contains a
directory or a file, instead of trying to both join a path AND then deal
with prettifying it or its basename.  This allows consumers to join
paths themselves (and apply any necessary rules - like fitting within
MAX_PATH).

There was no test ensuring that we validate `.git` paths.  We do, but
let's add a test to make sure that we never regress this.

Introduce `git_path_validate_filesystem` which validates (absolute) on-disk
paths and `git_path_validate_workdir` to perform validations on (absolute)
working directory paths.  These functions are useful as there may be system
limitations on on-disk paths, particularly on Windows (for example,
enforcing MAX_PATH).

For working directory paths, these limitations may be per-repository, based
on the `core.longpaths` configuration setting.

If we want to validate more and different types of paths, the name
`git_path_validate` makes that easier and more expressive.  We can add,
for example, `git_path_validate_foo` while the current name makes that
less ergonomic.

Move the utf8 functions into a proper namespace `git_utf8` instead of
being in the namespaceless `git__` function group.  Update them to
have out-params first and use `char *` instead of `uint8_t *` to match
our API treating strings as `char *` (even if they truly contain `uchar`s
inside).

The info pointer was allocated with git__malloc, so needs to be free'd with git__free.
This bug can lurk pretty easily since if there's no custom allocator this is fine.

We've accumulated quite some functions which are never used outside of
their respective code unit, but which are lacking the `static` keyword.
Add it to reduce their linkage scope and allow the compiler to optimize
better.

Windows/DOS only supports drive letters that are alpha characters A-Z.
However, you can `subst` any one-character as a drive letter, including
numbers or even emoji.  Test that we can identify emoji as drive
letters.