Meta-issue: QHULL, Bad Data, and Potential Fix

The qhull failure error pops up every so often, almost always with data that is "bad" in some way.
The most common factor seems to be multiple co-incident images (bad/slow GPS metadata updates/writing).

A potential fix for this would be to "jiggle" the co-incident images around by adding precision to their reported location and randomizing the location in that extra precision, thus scooching them around enough to no longer be co-incident and then hopefully able to be processed.

A method to accomplish this might look like detecting this issue early on, writing a warning to the console, upon qhull failure generate a subsetted geo.txt for those images, feed it back in, restart processing, and away it goes.

GitHub Issues:
https://github.com/OpenDroneMap/ODM/issues/1566
https://github.com/OpenDroneMap/ODM/issues/1564

Community Threads:
https://community.opendronemap.org/search?q=qhull%20order%3Alatest

It looks like PCL is what pulls in qhull. Our PCL is v1.8 from 2016, and that relies upon qhull v6.x from 2010/2011.
There have been numerous releases of both libraries in the interim, and we might just get lucky in that a dependency bump here is all that is needed to address the failure mode with bad data with no special handling on our part (though a warning in the Log is probably a Very Good Thing (TM) anyway).

Start by tracing the QHULL failure path and reviewing how the PCL 1.8 and qhull 6.x dependencies are defined. Reproduce the failure with coincident or otherwise bad image-location data, then determine whether a dependency update or explicit handling is required; done means the failure mode is addressed and an appropriate warning is recorded.