An LLVM 19-aligned libc++ was released with macOS 15.4 (and corresponding OSes),
and LLVM-20 aligned with macOS 26.0. This patch adds availability markup to
reflect that.

This patch contains several changes to `deallocate_size.pass.cpp`:
1. `static_cast`-ing some parameters to `size_t` to avoid narrowing.
2. Changing the type of loop variable `i` to `unsigned int` avoid
signedness mismatch with the constructor parameter.
3. Separately counting allocations and deallocations in variables
`allocated_` and `deallocated_`, and changing their type to `uint64_t`.
4. Avoiding `assert`-ing count of allocations when a `basic_string` is
allocated, just `assert`-ing after destruction instead.

Verify that the operation passed to resize_and_overwrite returns an
integer-like type, matching the behavior of other standard library
implementations like GCC's libstdc++

Fixes #160577

We've built up quite a few links directly to github within the code
base. We should instead use `llvm.org/PR<issue-number>` to link to bugs,
since that is resilient to the bug tracker changing in the future. This
is especially relevant for tests linking to bugs, since they will
probably be there for decades to come. A nice side effect is that these
links are significantly shorter than the GH links, making them much less
of an eyesore.

This patch also replaces a few links that linked to the old bugzilla
instance on llvm.org.

Currently, when the string shrink into the SSO buffer, the `__rep_.__s`
member isn't activated before the `traits_type::copy` call
yet, so internal `__builtin_memmove` call writing to the buffer causes
constant evaluation failure. The existing test coverage seems a bit
defective and doesn't cover this case - `shrink_to_fit` is called on the
copy of string after erasure, not the original string object.

This PR reorders the `__set_short_size` call, which starts the lifetime
of the SSO buffer, before the copy operation. Test coverage is achieved
by calling `shrink_to_fit` on the original erased string.

In 0547e573c555, I introduced backdeployment testing on macOS using
Github-provided builders. This was done by basically building libc++ on
a slightly older macOS (like macOS 13) and then running against the
system library on that machine. However, that created a dependency that
libc++ must keep working on macOS 13, which doesn't support the
latest-released Xcode.

This patch solves that problem by moving the deployment testing to a
newer version of macOS which supports the latest-released version of
Xcode.

Sadly, that also reduces the backdeployment coverage we have since we're
not actually testing on older OSes, but is necessary to satisfy the
documented libc++ support policy. In the future, we could improve the
situation by providing a Lit configuration that allows compiling (but
not running) all the tests, building the tests on a supported macOS, and
then shipping those tests on an older backdeployment target in order to
run them against the system library. Since that requires significant
engineering, this isn't done at this time.

Without this patch `basic_string` cannot be properly resized to be
`max_size()` elements in size, even if an allocation is successful.
`__grow_by` allocates one less element than required, resulting in an
out-of-bounds access. At the same time, `max_size()` has an off-by-one
error, since there has to be space to store the null terminator, which
is currently ignored.

The current implementation of the `shrink_to_fit()` function of
`basic_string` swaps to the newly allocated buffer when the new buffer
has the same capacity as the existing one. While this is not incorrect,
it is truly unnecessary to swap to an equally-sized buffer. With equal
capacity, we should keep using the existing buffer and simply deallocate
the new one, avoiding the extra work of copying elements.

The desired behavior was documented in the following comment within the
function:


https://github.com/llvm/llvm-project/blob/61ad08792a86e62309b982189a600f4342a38d91/libcxx/include/string#L3560-L3566

However, the existing implementation did not exactly conform to this
guideline, which is a QoI matter.

This PR modifies the `shrink_to_fit()` function to ensure that the
buffer is only swapped when the new allocation is strictly smaller than
the existing one. When the capacities are equal, the new buffer will be
discarded without copying the elements. This is achieved by including
the `==` check in the above conditional logic.

The capacity is now passed correctly and a test for this path is added.

Since we changed the implementation of `reserve(size_type)` to only ever
extend,
it doesn't make a ton of sense anymore to have `__shrink_or_extend`,
since the code
paths of `reserve` and `shrink_to_fit` are now almost completely
separate.

This patch splits up `__shrink_or_extend` so that the individual parts
are in `reserve`
and `shrink_to_fit` depending on where they are needed.

This reverts commit 59f57be94f38758616b1339b293b43af845571af.