P3935 `fadd` et al. should probably not be `noexcept`

[eisenwave]

I think I imitated std::lerp (which is noexcept) when designing this, but std::hypot (three parameters) is much more relevant precedent, and that one is not noexcept.

[frederick-vs-ja]

I guess templated fadd is possibly expected to forward parameters to C stuffs which are not marked noexcept, so it shouldn't be noexcept either. However, on the other hand, as these functions are marked constexpr and thus there must be C++-specific handling, perhaps noexcept can make some sense.

I think it would be more consistent to remove noexcept from P3935 and have a new paper to explore adding noexcept to constexpr-ized or C++-specific <cmath> functions whenever possible.