drawing. We are still very slow, though:

- we should preprocess the mesh to draw large triangle/line strips
- we should store the normals (and NOT IN A SET!!)
- we should store the elements in a structure allowing a faster traversal
- we should do all this in single precision

The same remarks apply for the post-processing stuff. Worse, in
post-pro, due to Get_Coord and SaturateValues, we basically copy ALL
THE DATA SET at least one per drawing, even when we don't have to (no
Raise/Offset/Saturate)... This is horrible, and makes us lose all the
advantage of the fast list_PointerFast stuff I designed in the forst
place. Ahhh, the cost of generality...

Msg) firing a 2nd draw() before the fir(st has finished... This is a
general problem with our "pseudo-threaded" (i.e. putting many
WID->check() calls) approach... I added a new lock in draw() (we
already have one in Generate()), but this is pretty ugly.

"save as" stuff. This will only work with fltk > 1.1.0rc4 (Michael
Sweet added 2 functions to the fltk file chooser specially for us!)

compilation directives (cf. __APPLE__), were to rename the type
ColorTable to GmshColorTable and the function Palette to Palette1,
in order to avoid conflicts with Apple's QuickDraw.
Note that HFS is case-insensitive, which requires to have a fltk lib
name otherwise than libfltk.a (in the Mac version, the GL part is separate
anyway, so I've been using libfltk_base.a and libfltk_gl.a).