Add copysignf16, copysignf128, fabsf16, and fabsf128

[tgross35]

Add generic versions of abs and copysign, which is used to implement f16 and f128 versions of these functions. These currently aren't tested because the builtin musl tests don't provide a reference, but the implementations are straightforward and we will be able to test against #311 once it lands. (Technically musl on aarch64 has fabsl and copysignl as f128, but I don't think it is worth updating the serialization tests).

The second commit ("Add float and integer traits...") just copies the exact trait implementations that we use in compiler-builtins, with the assumption that we will use it more in the future and for testing.

The third commit ("Add f16 and f128 configuration...") copies the logic from compiler-builtins for setting enable_f16 and enable_f128 with the exception that here, the unstable feature must also be enabled. This will probably need to be tweaked a bit in the future so it isn't tied to other behavior enabled by unstable, but this is enough to get us started.

[burrbull]

Using traits blocks us from using functions in const context, is not it?

[tgross35]

It would indeed prevent us from making any of the public functions const (none of them are now), but providing const implementations is out of scope for this crate. Instead, there is work that can be done so that the equivalent functions in rust-lang/rust can become const, e.g. const { 100.0f32.cos() } will work.

I have some more details here if you are interested #310

[burrbull]

is out of scope for this crate

Who has decided this?

[tgross35]

It has been a goal for a while to make the float math functions available in core, which require various changes in this crate (improving accuracy, testing across all targets, performance, supporting the new float types). Conveniently, figuring out those same things will allow us to make the functions in std/core const. If that gets done then there won't be much use for this crate in its current form - so making that happen seems like a much better time investment.

The existing implementations aren't going away either. Generic methods just make it easier to support f16 and f128, as well as f32 algorithms that don't rely on f64 (for cases where there is no hardfloat f64).

[tgross35]

Superseded by a handful of PRs, including #386.