In https://github.com/libgit2/libgit2/pull/5723/files/fc46dc06f52f854f74371682f911f13856c68edb#r540092847, I was confused by the semantics of `git_index_find`. The documentation says both that it returns the output value in `at_pos` and that it returns it directly as an `int`. This is incorrect; the return value is only returned via `at_pos`.

tests: clean up memory leak, fail on leak for win32

Fix issues with Proxy Authentication after httpclient refactor

Fix documentation formatting

Update README.md for additional Delphi bindings

Manually merging #5842

When a split src gets turned into a rename, it should
also lose the IS_RENAME_TARGET flag, so that it doesn't
get processed in a subsequent iteration as a rename target.
Doing so can cause an assertion failure because it no
longer has the SPLIT flag.

Fixes #5811.

buf: remove unnecessary buf_text namespace

filter: stop taking git_buf as user input

Instead of a `git_bom_t` that a `git_buf` function returns, let's keep
it `git_buf_bom_t`.

The `git_buf_text` namespace is unnecessary and strange.  Remove it,
just keep the functions prefixed with `git_buf`.

Introduce `git_filter_list__convert_buf` which behaves like the old
implementation of `git_filter_list__apply_data`, where it might move the
input data buffer over into the output data buffer space for efficiency.

This new implementation will do so in a more predictible way, always
freeing the given input buffer (either moving it to the output buffer or
filtering it into the output buffer first).

Convert internal users to it.

Deprecate `git_filter_list_apply_to_data` as it takes user input as a
`git_buf`.  Users should use `git_filter_list_apply_to_buffer` instead.

Provide a filter application mechanism that takes a user-provided string
and length, instead of a `git_buf`.

The API `git_filter_list_apply_to_data` shares data between its out and
in parameters to avoid unnecessarily copying it when there are no
filters to apply.  However, it does so in a manner that is potentially
confusing, leaving both `git_buf`s populated with data.  This is risky
for end-users who have to know how to deal with this.  Instead, we
remove this optimization - users who want to avoid unnecessary copies
can use the longstanding streaming API or check the filter status before
invoking the filters.

`git_filter_list_stream_data` takes user input in a `git_buf`.
`git_buf` should only be used when libgit2 itself needs to allocate data
and returned to a user that they can free when they wish.  Replace it
with `git_filter_list_stream_buffer` that takes a data buffer and
length.

test: clean up memory leaks

Support `core.longpaths` on Windows

ci: use GitHub for storing mingw-w64 build dependency

Working directory path validation

Ensure that a repository's path (at initialization or open time) is
valid.  On Windows systems, this means that the longest known path
beneath the repository will fit within MAX_PATH: this is a lock file for
a loose object within the repository itself.

Other paths, like a very long loose reference, may fail to be opened
after the repository is opened.  These variable length paths will be
checked when they are accessed themselves.  This new functionality is
done at open to prevent needlessly checking every file in the gitdir
(eg, `MERGE_HEAD`) for its length when we could instead check once at
repository open time.