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.
I wonder too