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

This lets `feh` draw the background pixmap of an existing window,
opening the door for use with tools like `xscreensaver` or `xsecurelock`

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.