`updateImage` process breaks huge images (X11)

**NOTE**: this assumes that the code in `Fl_JPEG_Image::load_jpg_` and `Fl_RGB_Image::copy` has been modified to handle an image w * h * d that may exceed INT_MAX.

`updateImage` uses Fl_Image_Surface to draw the checkerboard and combine with the work image, and calls Fl_Image_Surface::image to fetch the results.

`Fl_Image_Surface::image()` has an limitation imposed by X11's `XGetImage()` function. The [code for `XGetImage()`](https://raw.githubusercontent.com/mirror/libX11/5faa8dc0b364f55f19034c370436074646d9ad54/src/GetImage.c) appears to be limited to handling at max (INT_MAX >> 2) pixels, or 536,870,911 pixels.

This is partially confirmed by the fact that:
- ["Garden of Earthly Delights"](https://commons.wikimedia.org/wiki/File:The_Garden_of_Earthly_Delights_by_Bosch_High_Resolution.jpg) 30,000 x 17,078 [512,340,000] succeeds [a bit under the threshold]
- ["The Ambassadors"](https://commons.wikimedia.org/wiki/File:Hans_Holbein_the_Younger_-_The_Ambassadors_-_Google_Art_Project.jpg) : 30,000 x 29,560 [886,800,000] fails with "X I/O Error".
- ["garden of earthly delights"](https://commons.wikimedia.org/wiki/File:The_Garden_of_earthly_delights.jpg) 39,137x22,279 [871,933,223] fails with a stream of XBadDrawable errors and a SEGFAULT.

536,870,911 bytes is a max of 30,000 x 17,895 and could be verified by cropping "The Ambassadors" to that size.

Possible solutions:
1. If the image h*w exceeds some arbitrary threshold then `updateImage` needs to skip the usage of Fl_Image_Surface.
2. Break the Fl_Image_Surface::image() calls into smaller segments and re-combine
3. Investigate `XShmGetImage` as an alternative to `XGetImage`
4. punt

It would be helpful if Fl_Image_Surface had better error handling to deal with the "X I/O Error" and "XBadDrawable" errors, without exiting the application.