FMSLogo Code

Refactoring
- Extract a function for commonality between SetWrappedPixel/GetWrappedPixel
- Add min4/max4, which is clearer than nested min/max calls.
- Improve comments

Fix Bug #578; OPENWRITE, OPENREAD, OPENAPPEND, and OPENUPDATE can now open files with names that have special characters quoted by vertical bars.
The problem was that the remapping of the special characters that marked them as vbarred wasn't undone before passing the filename to fopen().

Update BITLOAD.MALFORMED to match the behavior of wxImage

Add a commented out directive to use a large address space.
This, along with a boot configuration change, enables a 32-bit program to use 3GB of memory on a 64-bit host OS.
There is some compatibility risk, so it's disabled until I can test it well.

Use the calculated realsize in debug_malloc instead of calculating it twice.

Fix a regression introduced when using wxImage to load bitmaps.
If the biClrUsed was negative or large, wxImage::LoadFromFile would throw a bad_alloc exception, causing FMSLogo to crash.
This is now patched in the library and (in case an unpatched library is used) also handled in FMSLogo.

Fix some bugs that prevented bitmaps from loading on GNU/Linux
1) Reading the header size assumed that long was four bytes.
Now it uses char and checks the magic numbers, not the BITMAPINFOHEADER size.
2) Fix a double-free (fclose was called twice due to incorrect usage of FFile)

Fix Bug #577; By rewriting OpenDIB in terms of wxImage/wxBitmap it can now read top-down bitmaps.
It still cannot handle 16bpp top-down bitmaps, which may be a bug in wxWidgets.
It also now leaks memory when loading malformed bitmaps. This may also be a bug in wxWidgets.

In addition to fixing this bug, using wxWidgets should enable bitmaps to be loaded on GNU/Linux (GTK+).

Fix some typos in file names in BITLOAD.16BPP

Integrate 8bpp-1x64000.bmp and rle8-64000x1.bmp into the test pass.
I had commented them out because I mistakenly thought that they weren't being rendered due to a bug. In fact, they are "large enough" that they are rendered in the upper-corner top-down and I just didn't notice this because I (incorrectly) expected to see them drawn at the turtle's location.