Don't let compiler-builtins' weak math definitions shadow system libm

[cezarbbb]

fix issue #142119 (Not yet)

compiler-builtins emits weak definitions for the f32/f64 math functions (its full_availability module) so no_std targets without a system libm still work. The trouble is that when the link also records libm (-lm), those weak definitions come before -lm and get pulled in first, so ceilf/sqrtf and friends resolve to compiler-builtins instead of glibc (#142119). This bites in two places: binaries/cdylibs where rustc does the link itself, and staticlibs that bundle the weak definitions for the consumer.

For the self-link case this emits -lm before the upstream rlibs on glibc targets that record -lm, so glibc's strong definitions win. I chose to move -lm forward rather than move compiler-builtins back, because moving only -lm fixes the math symbols without also flipping which of the compiler-builtins/libgcc intrinsic overlaps wins — those stay as they are.

For staticlibs it omits the 28 overlapping weak f32/f64 math members from compiler-builtins' rlib when -lm is recorded, so the consumer's libm provides them. (The rename-based alternative was discussed on Zulip and set aside.) There's a run-make test covering the positive case, the no--lm control, and a check that the omission isn't a blanket strip (f16/f128 and integer fallbacks survive).

This is a draft to get the direction in front of people. The staticlib skip depends on compiler-builtins being left out of LTO (ignored_for_lto) — that's the only reason its members are still individual objects to skip, and the debug_assert! in link_staticlib spells that assumption out. @bjorn3 floated the idea of moving rustc-driven LTO into link_binary, which would let us skip objects before the LTO merge instead of relying on that; nothing along those lines has landed yet, so I've kept the assert to flag it and would adapt the skip when (if) that happens. The main thing still open is which symbols to omit — whether the 28-symbol list is the right cut, or f16/f128/roundeven should be included too.

r? @bjorn3 @tgross35

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.