Instead of tweaking the `stdalloc` allocator when
`GIT_DEBUG_STRICT_ALLOC` is defined, actually create a debugging
allocator. This allows us to ensure that we are strict about things like
not expecting `malloc(0)` to do something useful, but we can also
introduce an excessively pedantic `realloc` implementation that _always_
creates a new buffer, throws away its original `ptr`, and overwrites the
data that's there with garbage. This may be helpful to identify places
that make assumptions about realloc.

realpath(3) _may_ allocate strings (if the second param is NULL) using
the system allocator. However, callers need an assurance that they can
free memory using git__free. If we made realpath do an allocation, then
make sure that we strdup it into our allocator's memory.

More importantly, avoid this behavior by always providing a buffer to
p_realpath invocations.

Instead of setting the allocator to stdalloc, just pass `NULL`, in case
we're running with the debug allocator.

Use new-style links to the build information and badges, which link to the workflow filename, not the display name.

Introduce a stricter debugging allocator for testing

This reverts commit cf19ddc, which
was breaking for several projects.

README: add experimental builds to ci table

 Fix constness issue introduced in #6716

libgit2 v1.8.2