Tolerate readlink size less than st_size

Patch documentation

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