Remove the `libm` dependency and inline the functions we use?

Nobody has claimed this yet.

Right now, we depend on the `libm` crate to implement floating-point math operations like `floor`, `ceil`, and `sqrt` that are implemented as intrinsics in practice but are still [not exposed in `core`](https://github.com/rust-lang/rust/issues/137578).

There are various reasons we might not want `libm`.

It has its own architecture-specific implementations for some operations, but per-architecture support is patchy--some operations are missing even though they are supported by the underlying architecture. [They are also implemented using inline assembly](https://github.com/rust-lang/compiler-builtins/issues/1027) instead of intrinsics, which inhibits potential optimizations. This is apparently done to avoid recursion when using the `libm` crate as the libm implementation for *Rust itself*, but that doesn't apply when using it here.

It also [performs its own feature detection](https://github.com/rust-lang/compiler-builtins/blob/eba1a3f3d2824739f07fe434624b0d2fee917d89/libm/src/math/arch/x86/detect.rs), which is pure overhead and completely redundant with the feature detection we perform here.

I think there's room for a slimmer version of the `libm` crate that implements *only* the operations from the `core_float_math` feature. It shouldn't perform any runtime feature detection, and should use intrinsics when possible and inline assembly if the architecture's intrinsics are not stabilized.

Start by auditing the current libm dependency and the operations covered by the core_float_math feature. Compare the architecture-specific implementations and feature-detection concerns described in the issue; done means an agreed scope for a slimmer implementation and a decision on whether to inline or replace the dependency.

Written by the indexing model from the issue text.