glibc SFrame support for newer versions

[Adhemerval Zanella Netto]

The glibc has optional support for SFrame through a configure switch
(--enable-sframe), added in 2.42.

In a recent discussion about adding SFrame support to LLVM [1], Fangrui
pointed to a binutils thread where Indu stated [2] that v3 was the
version intended to "targeting to converge to and start from (in userspace)".

I do not intend to discuss whether SFrame has the right design or any
other point already being discussed in multiple threads.

My point is how we should handle glibc SFrame support in upcoming versions,
especially given potential mismatches across libraries. Would just bump
support to v3 and ignore v2 objects, as we currently do on sframe_header_sanity_check_p for v1? 

This is not the usual way we handle public APIs; however, since it is
currently an optional feature not widely deployed, it can be something
we can do without much breakage. This can work as long as the sframe is
optional. Once we add it as a default option (and I would like to
eventually do it in the future), we will need to support multiple
versions. I am not sure if this is possible or if this will be a
problem in future versions.

I wonder if it would be better to make it similar to how we handle
libgcc_s.so and move the sframe support to a library outside glibc
(so any supported version would be handled by the system libraries,
instead of glibc itself).

[1] https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900
[2] https://sourceware.org/pipermail/binutils/2025-October/145028.html