RFC: Fixes for the lava puzzle and generic handling of floating point rounding issues

This patch set fixes a bunch of issues seen especially in the lava puzzle:

### Boats don't collide
* since the boats are not moved via WalkActorTo but via SetActorAt, handleCollisionWith() was never called and so the LUA callback to handle the collision was not called as well
* simple bug fix: call handleCollisionWith() in Actor::setPos(), too - this  fixes #877 

### Boats are invisible
* running residualvm via apitrace revealed, that the boat's vertices consisted of just NaNs and so they were ignored by the OpenGL implementation
* they were computed using quats which contained just NaNs which were computed by normalizing a (0, 0, 0, 0) quat (which is basically a division by zero)
* commit b1af372 fixes this issue (#1107)

### 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?
* To avoid unexpected trouble by the new asserts(), would it make sense to define NDEBUG for builds with --enable-release?
* 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.
Done. Probably that value could be even moved to the more generic math/utils.h.