BUGFIX: Removed undefined floating point math behavior

When using floating point literals, e.g. via macros such as

define GIGANTIC 1e140

it can happen that different architectures (x86 versus x86_64)
trigger different rounding scenarious during assignments and
expressions. This can lead to failing floating point comparisons
(via ==) even if both sides of the comparison are identical (if
floating point expressions should be compared via == is a whole
different question of course). Unfortunately, the exact behavior
depends on the IEEE compliance of the compiler, the C standard,
etc. In gcc, the behavior can be controlled via the
-fexcess-precision switch but this seems non-portable.
The fix (which might be a hack) which I've implemented
for now is to explicitly cast floating point literals to their
precise type, i.e.

define GIGANTIC (double)1e140

which appears to force the correct behavior.

NOTE: This fixes issue #5 on the MCell issue tracker.