RFC: Generic handling of floating point rounding issues

I have split the original PR #1108 into two PRs. The actual bug fixes for the lava puzzle and the generic handling of the floating point problems.

### Generic floating point issues
* in floating point, some operations are valid (like x / 0.0f) but have an unexpected outcome (+/- inf for x!= 0  or NaN for x = 0.0f)
* these special values are propagated undetected through all calculations and may lead to strange effects (like the invisible boats)
* due to the nature of the limited accuracy of floating point operations, some calculations are critical:
  * arcus cosinus/sinus if variable is outside of -1.0 ... 1.0
     * e.g. the operand of arcCosine is sometimes just a little bit above 1.0: 
<pre>Angle::arcCosine(dotProduct(v1, v2) / (v1.getMagnitude() * v2.getMagnitude()));</pre>
     * even the mathematically valid formula like the one above may produce results which are just a little bit off due to float's accuracy and so they would cause effectively acosf() to generate NaN
  * division by zero: can cause +/-inf or NaN
  * probably others like sqrt() of the operand is smaller than 0.0f
* in order to track down these issues I have enabled the reporting of floating point exceptions when project is not compiled with --enable-release
* for the revealed exceptions I did the following:
  * added asserts in the low-level math classes when undefined values are calculated or when the objects are created with undefined or non-meaningful values (like a line with no direction or a segment where the start and end point are equal)
  * fixed this kind of usage in the higher-level objects (e.g. in Grim::Actor)

### Open items
* Is that approach helpful at all?
* Enable the reporting of floating point exceptions in all 3 games and play some more scenes in order to detect other areas where the inaccuracies of floating point operations could cause some trouble.
What's the point of this? asserts should already be disabled for release builds.