Fixes https://github.com/derf/feh/issues/580

Note that Imlib2 does not support HEIC/HEIF images out of the box. However, the
imlib2-heic loader (https://github.com/vi/imlib2-heic) does.

Closes #579

Closes #577

This fixes two memory bugs that only manifest with exif=1 and long-running
slideshows.

* when feh loads an image, it writes exif data to file->ed. Previously, this
  data was never free'd, causing a memory leak on subsequent loads of the same
  file.
* As file->ed is never free'd, the accumulated EXIF data consumes a significant
  amount of memory over time. with slideshow-delay = 10 and two days of
  runtime, feh may exceed 1 GB of memory usage. If the slideshow is so large
  that feh does not encounter the same image twice in this time, this is not
  detected as a memory leak, as each EXIF data chunk is referenced from the
  filelist.

See <https://github.com/derf/feh/issues/553> for details.

Closes #553

If --edit is set, it is indeed "Edit in Place". Otherwise, it changes the
view, but not the image on the disk.

This works around a regression in Imlib2, which makes (un)loadable file
detection quite slow when handling e.g. large video files. See
<https://phab.enlightenment.org/T8739> and
<https://github.com/derf/feh/issues/505> for details.

Closes #505

Issue:

* start feh --multiwindow --reload 5
* close a window with "x"
* wait up to 5 seconds
* segfault

The issue was caused by the closed window's reload timer still being active
even after the winwidget was free'd.

Introduced in 3fa39154

When the slideshow state is toggled, the info line needs to be redrawn as it
may use the %a format specifier (which shows whether the slideshow is running
or paused). feh_reload_image does this, but also resets all pan and zoom
options and reloads the image from disk. winwidget_render_image only redraws
info, caption and similar lines in this case, which is more efficient and does
not incur unwanted side-effects.

The --version-sort option requires strverscmp(), but this is a glibc
extension that does not exist on OpenBSD and other systems. To enable
--version-sort on those systems, provide an internal implementation of
strverscmp(). The implementation is from the musl C library and is
MIT-licensed.

The build process remains the same: the verscmp flag should be set to 1
only if strverscmp() is available in libc. If verscmp is 0, then the
internal implementation is used.

Closes #532

Closes #521

feh_file_info_load is called even if file_info is already populated, so
the original file_info struct is never freed. This results in a leak of
~44 Byte for each subsequenc image load

Building feh 3.3 on CentOS 7 x86_64 warns `curl_quit_function` in `imlib.c` is unused:

```
cc -g -O2 -Wall -Wextra -pedantic -std=c11 -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -DHAVE_LIBCURL -DHAVE_VERSCMP -DHAVE_LIBXINERAMA -DHAVE_LIBEXIF -DPREFIX=\"/usr/local\" -DPACKAGE=\"feh\" -DVERSION=\"3.3\"   -c -o imlib.o imlib.c
imlib.c:545:12: warning: ‘curl_quit_function’ defined but not used [-Wunused-function]
 static int curl_quit_function(void *clientp,  curl_off_t dltotal,  curl_off_t dlnow, curl_off_t ultotal, curl_off_t ulnow)
            ^
```
The `curl_quit_function` code was added in response to pull [#435](https://github.com/derf/feh/pull/435)

In issue [#485](https://github.com/derf/feh/issues/485) a fellow CentOS 7 user had an error building feh because CentOS 7 is locked into an old version of libcurl. In the fix, a version guard was wrapped around the `curl_easy_setopt` call, but the rest of the code was unchanged.

Since I don't want to maintain a local build of libcurl, I looked at the curl docs and noticed there is an older callback which serves the same purpose: https://curl.haxx.se/libcurl/c/CURLOPT_PROGRESSFUNCTION.html

The difference between `PROGRESS` and `XFERINFO` is the callback's argument types, with `PROGRESS` using `double` and `XFERINFO` using `curl_off_t`: https://curl.haxx.se/libcurl/c/CURLOPT_XFERINFOFUNCTION.html

The callback's return value logic and use of `CURLOPT_NOPROGRESS` is the same.

For context, the latest libcurl RPM I'm getting from yum updates is `libcurl-7.29.0-54.el7_7.2.x86_64`. The "stable" versions of other distros may encounter similar issues. The CentOS 7 "End of Life" date is 2024-06-30 so you should hear the end of this by then, at least from us pesky CentOS users.

Closes #485

This can happen with images that have ridiculous dimensions.

This ensures that X11 layout or other changes do not affect the .fehbg
contents, which are meant to only be updated when a --bg-option is used
manually.

Closes #482

When setting wallpapers without --no-fehbg option, a ~/.fehbg file is
created. This file is set to be an executable for later re-use.

Calling stat() without checking the return value can lead to issues.
If the call fails, then s.st_mode is undefined and excessive permissions
could be set to .fehbg, at worst even setuid/setgid bits for a world
writable file.

While adjusting this, I changed the code to use fstat() and fchmod() to
avoid a further -- but very unlikely -- issue: race condition in form of
TOCTOU. If the file ~/.fehsetbg is replaced by a symlink right before
the chmod call, then a different file would be set executable + the
default mode of the (newly created) file. I don't expect this to be a
real world issue but changed this part "while at it" anyway for more
robust code and a good example on how to handle files.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

That part slipped through while reviewing the PR...