Switch to floating point audio and control data

[olofson]

It's about time to go where everyone else have long since gone: Floating point.

(See also #28.)

Implementing any non-trivial DSP code in integer/fixed point is an absolute PITA, even with 64 bit integers, which are probably still less portable than floating point. Thought it used to be a bit of a gray zone, I'm pretty certain that by now, the constant renormalizing and over/underflow avoidance hacks also make integer/fixed point slower than floating point on any non-ancient hardware.

The potential downsides of floating point, that we need to watch for:

• Denormal processing
  AFAIK, falling outside the dynamic range of the exponent field still results in EXTREMELY expensive special handling in most/all FPUs, and absolutely needs to be avoided. On some platforms, denormals can be disabled (automatically truncated to 0, I presume?), whereas on other platforms, "risky" DSP code needs to actively avoid generating denormals, by adding a microscopic (-300 dB ballpark for 32 bit float) DC offset, noise or similar, cut processing when effectively silent, or similar.
• Determinism
  We can't rely on things to nicely truncate to 0 (or any particular target value) at exact points in time, and maybe we shouldn't rely on subtle details of the FPU at hand either, even though most seem to implement the same standard these days. There are probably a bunch of cases where we need to be more explicit about states and conditions than the current code.
• Integer/floating point casting performance hits.
  Arrays and tables still need to be indexed, and we still deal in integer numbers of samples. Conversion can be quite expensive, so it may make sense to run oscillator indices and the like with both integer (index) and floating point (DSP) "iterators" in parallel where applicable. Obviously, it's real handy to already have the working integer/fixed point code needed for this!
  Wrapping is not a thing with floating point, so we might just keep the event timestamps as is...? 256th sample resolution "should" be enough, I think, and the current problem areas (long time deltas for envelopes and the like, and iterative updates of oscillator phase) could probably be handled with floating point code.