oiiotool: work around static destruction order issue (AcademySoftware…

…Foundation#3295) (AcademySoftwareFoundation#3591)

In some cases (at least on Windows, with static linking) the oiiotool
main returns zero, but the full process returns 3 error code due to
abort() being called. And that is called because a global shared
image cache is already destroyed, but the image references from another
global (Oiiotool itself) try to use it, get a call into a "pure virtual
function" stub that is put by MSVC C runtime into a destroyed object
vtable, and that ends up in an abort().

Work around that by making sure various member variables holding
ImageRecRef are cleared before main() finishes and global destructors
are called.

src/oiiotool/oiiotool.cpp

@@ -6603,6 +6603,14 @@ main(int argc, char* argv[])
     // field3d when building with EMBEDPLUGINS=0 on MacOS.
     ot.imagecache->close_all();
 
+    // Release references of images that might hold onto a shared
+    // image cache. Otherwise they would get released at static destruction
+    // time, at which point due to undefined destruction order the shared
+    // cache might be already gone.
+    ot.curimg = nullptr;
+    ot.image_stack.clear();
+    ot.image_labels.clear();
+
     // Force the OpenEXR threadpool to shutdown because their destruction
     // might cause us to hang on Windows when it tries to communicate with
     // threads that would have already been terminated without releasing any