Documents arithmetic reduction semantics

[gnzlbg]

This PR documents the arithmetic reductions and updates stdsimd to the latest changes in the RFC:

• sum -> wrapping_sum
• product -> wrapping_product
• min -> min_element
• max -> max_element.

Currently there are two open issues that affect computations involving NaNs:

• llvm.experimental.vector.reduce.f{min,max} do not behave like we'd like with respect to NaNs due to min_element / max_element produce incorrect results for NaNs in the last place #408 (which points to the LLVM bug). Basically, we want these to behave like min/max for floating point numbers, that is, they should always return a number unless all elements in a vector are NaN just like IEEE-754 {min,max}Num and {minimum,maximum}Number do. Right now, they behave more like fcmp+select, producing different results depending on where NaNs are situated inside a vector. For example, (NaN, 1., 2., -1.).min_element() returns -1. but (-1., 1., 2., NaN).min_element() returns NaN...

• llvm.experimental.vector.reduce.f{add,mul} are a bit broken upstream and only work with math flags enabled. . . (see floating-point sum / product are buggy w.r.t. NaNs #409 which points to the LLVM bug). They do produce correct results AFAICT, but because fast-maths are enabled code around these makes incorrect assumptions about their results when they are NaN. For example: (1., 2., NaN, 4.).wrapping_sum() returns NaN but (1., 2., NaN, 4.).wrapping_sum().is_nan() returns false...

We should work around these in stdsimd.