There is also an alternative WcsGetDefaultColorProfile() path
that might be necessary on some broken versions of Microsoft Windows,
which I certainly do not want to support.
Windows and Linux applications are more likely to not bother,
and their desktop environments don't place windows right in the corner,
which is what happens with GTK+/macOS.
Linux has st_mtim (and an st_mtime macro),
macOS has st_mtimespec (and an st_mtime macro),
Windows has just st_mtime.
GFileInfo would be another option, though it seems unnecessary.
It would also be possible to handle this through press/motion/release
event handlers, though GtkGestureDrag is more convenient for hacking in
support for dragging to widgets not supporting GtkScrollable (yet).
There may be some undesired interactions lurking, besides the jarring
movements when dragging native GdkWindows (these are a pain).
And store all direct thumbnailer output in the browser's cache--
low-quality thumbnails will always be regenerated, as is desired,
and we'll reload faster on devices where we don't store thumbnails.
This change improves latency at the cost of overall efficiency,
seeing as images with thumbnails will be spent cycles on twice.
Keeping this out-of-process avoids undesired lock-ups.
Moreover, embedded thumbnails can be fairly expensive to decode.
It still needs no versioning, as it's not really used by anyone.
An alternative method of passing a "low-quality" flag would be
perusing fiv_thumbnail_key_lq from fiv-thumbnail.c, which would
create a circular dependency, unless fiv_io_{de,}serialize*()
were moved to fiv-thumbnail.c.
This will speed up sort changes, as well as simple reloads,
at the cost of an extra hash map from URIs to Cairo surface references.
It seems unnecessary to provide an explicit option to flush this cache,
as it may be cleared by changing either the directory or the current
thumbnail size.
