use fma in decoding

[ericphanson]

closes #146

Here the main question is whether to use muladd or fma. Quoting the muladd doctsring,

help?> Base.muladd
muladd(x, y, z)

Combined multiply-add: computes x*y+z, but allowing the add and multiply to be merged with each other or with surrounding operations for
performance. For example, this may be implemented as an fma if the hardware supports it efficiently. The result can be different on different
machines and can also be different on the same machine due to constant propagation or other optimizations. See fma.

The result being different on different machines sounds like the kind of thing we don't want to have to worry about with encode/decode when trying to track down reproducibility issues etc. Moreover, fma is widely available now. So I think it makes sense to stick with fma for an accuracy boost and speedup on most hardware, at the potential cost of a big slowdown for software emulation on unsupported hardware. I think all the hardware used at Beacon supports fma.

Note the existing tests pass as-is, including some floating point == tests, which I guess means we were already rounding correctly on the test data (?).

[jrevels]

project.toml bump before merging?

[palday]

If any results change, they're being changed to be more accurate, which I'm fine with. Moreover, if your signal is that sensitive to rounding errors in decoding (as opposed to in some iterative algorithm), you probably have bigger problems.

Apple M1 silicon has FMA support; on x86-64, both AMD and Intel chips have had good FMA support since 2012/2013, according to Wikipedia. So I'm not worried about a performance hit from software emulation.