Move galaxy.png from the root to data subdirectory
Fix Squirrel not to raise floating point exception when SQUSEDOUBLE

Making Squirrel native floating point number (SQFloat) a double (through
defining SQUSEDOUBLE macro) occasionally cause floating point invalid
exception in the hash function.

I'm not sure why this doesn't happen in non-SQUSEDOUBLE build, but we need
some workaround to get it working in double precision world.  And it seems
that Linux Gcc is also free from the exception.  Probably it's due to
floating point mask (which is configured strictly in VastSpace).

This silly workaround is reinterpreting pointer to the floating point
number to a pointer to an unsigned integer of the same size.  This may
or may not appropriate for a hash function, but at least we get unique
hash for distinct numbers.
Make Squirrel library use double precision floating numbers

We want to use Squirrel extensively for universe-wide scale, so using
double seems appropriate.

Nowadays, most scripting languages have floating point types with double
precision.  Namely, Python and Ruby do.  So, why not Squirrel does?

Using single precision may help a bit to save memory used by the VM stack,
but we've already used so many double precisions in our application.

After all, we already have size of 8 bytes for Squirrel objects since
a pointer is 8 bytes wide in x64.
Replace calc3() with sqcalc() to unify in-line calculator implementation

Calc3 is an very old one-line calculator module I have created some decades
ago.  I couldn't get rid of it for long time because Squirrel interpreter
has not been able to parse some floating number literal expressions.
Now that we patched Squirrel source to interpret them correctly, we
no longer need to keep 2 separate formula interpreters in stellar
structure definition files.

Compared to calc3(), Squirrel may take some more time to yield an
expression's value since it has more complex syntax and requires
bytecodes to be compiled first, but it would only be required once
at program startup.  The merit of unification of codes would easily
overcome this overhead.