In the image_remove function, slideshow_change_image needs to be called before
removing the image from the filelist.  Because of this, the "x of y" displayed
by --draw-filename is wrong (y is 1 too high).

This commit introduces a new 'render' argument to slideshow_chingae_image.
The image_remove function calls it with render=0, edits the filelist and then
runs by winwidget_render_image itself.

Patch by Yu-Jie Lin.

gib_imlib_save_image_with_error_return was used, but it tries to set the Imlib
image format by examining the filename to save to.  However, it only supports
lowercase file endings (as in .jpg) and breaks with others (like .JPG).

Since giblib is unmaintained, for now the fix is only used here.

This fixes a really weird bug where continued theme definitions containing
just one option/value pair caused feh to mis-parse parts of the following
line.

Apparently, subsequent realloc calls mixed with strdups in another function
caused parts of the list (argv) content to be overwritten by the content of
the list pointer itself. I wasn't able to find out the exact causes /
conditions.

Note that feh does not try to convert encodings or anything. It expects
filenames to be in UTF8 and passe them on to NET_WM_NAME and NET_WM_ICON NAME.
The only new thing is that it now also sets _NET_WM_NAME and _NET_WM_ICON_NAME
and explicitly tells X11 that they are in UTF-8. Again, no recode, if you use
UTF-8 filesystems (which you should), everything is fine.

This prevents a (highly unlikely) case of an attacker knowing feh's PID and
the user's URL rewriting user files by means of a TOCTTOU attack.

It is still possible to _create_ arbitrary files via dangling symlinks. That
will be fixed once I switch from wget to libcurl.