Fix broken list in README.md

The list of dependent libraries has been broken since migration from HTML to Markdown
Move syl.txt to data subdriectory

The path to this file is hard-coded into C++ source.
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.

Calc3() is a recursive descent parser which was good for simple
calculation, but we need more versatile parser to treat various
objects.  Specifically, we want to use vectors, quaternions and
matrices in expressions.
Delete calc3 sources since it's no longer used by anyone
Simplify StellarFileLoadInt() invocation

Specifically, removed struct varlist which is remnant of calc3.

Also removed extra allocation of Squirrel tables for local variables
to optimize delegate chain.
Fix color directive fails to interpret values in SSD files
Add Ceres.ssd to introduce Ceres, the largest object in the asteroid belt
Add DrawTextureCubeEx to draw sphere as inflated cube
Polish DrawTextureCubeEx to draw modulated terrain
Add skirts to hide gaps between panels
Import simplex noise implementation

From:
http://webstaff.itn.liu.se/~stegu/simplexnoise/

The original author is Stefan Gustavson, and the codes are in
public domain.

I have modified the source's extension to .cpp to make it be
able to build with Visual C++ without compile option tweaks,
since the source contains declaration after statements, which
is not allowed in ANSI C but C++.

Also added are static specifiers to perm variables to prevent
duplicate symbol errors at link time.
Generate random height map of TexSphere with simplex fractal noise
Make TexSphere use 3-D simplex noise to remove the need of skirts
Use Vertex Buffer Objects to enhance performance of DrawTextureCubeEx
Add texture mapping ability to DrawTextureCubeEx

Ceres demonstrates this functionality.
Implement very basic Level-of-Detail for DrawTextureCubeEx

This LOD determination is done per cube face (there are 6 of them), so
you won't get high detail for opposite side of the celestial body when
you walk on it.

This LOD granularity should become higher as the player apporaches the
surface to allow layered LOD tree for optimized rendering.
Implement Level-of-Detail in a cube face for DrawTextureCubeEx

Strangely, subdividing lod details actually makes it slower.