Image metadata parsing: new solution to asynchronous delays

Asynchronous metadata handling is tricky business, and no matter how I
try to improve the mechanisms behind this, I always run into problems.

The biggest trouble I face is that the connection between ExifTool and
PD is prone to unpredictable interruptions, especially when VB decides
that window messages need to be processed in some new and bizarre order.
These interruptions cause metadata parsing to unexpectedly (and
unpredictably) fail, when really all metadata has been processed just
fine, but VB has done something strange like postpone WM_TIMER message
processing until long after PD stopped waiting for metadata to arrive.
For reasons I have yet to understand, this was an especially common
occurrence after a common dialog was raised via keyboard accelerator.

To circumvent this, I am trying a new solution.  If an image has
finished loading but its full metadata report has yet to arrive, a timer
will now be activated on the main form.  This timer will silently wait
for metadata parsing to complete, and when it does, it will immediately
update the image with the metadata, then shut itself down.

Among other thing, this approach solves a recurring but unpredictable
problem where VB would unexpectedly halt StdOut checks, even for images
where ExifTool loaded metadata just fine.  Metadata will now *always* be
successfully loaded for loaded images, which is awesome!

That said, this approach introduces a new problem.  If the user loads a
bunch of images at once, metadata may get jumbled between the images,
because we have no way of knowing which StdOut metadata reports
correspond to which images.  I am not sure how to handle this just yet,
but I think it a fair trade to reliably fix metadata loading for
one-at-a-time image loads, at the cost of rare but possible issues with
many-at-once image loads.
Metadata parsing: solve asynchronicity problems once and for all

As described in the previous commit
(765cbbf1b9112d496395ff8baa3b2b10a66431ff), I didn't know if it was
possible to solve the nasty problem of sorting out individual image
metadata entries when the user loads a bunch of images at once, and VB's
interference with StdOut pipe reads causes the metadata for all images
to be returned as one contiguous string.

But a solution has presented itself!  ExifTool, as usual, comes to the
rescue, with an awesome feature where the caller can supply a custom
value for the program to return once it finishes processing a given
request
(http://www.sno.phy.queensu.ca/~phil/exiftool/exiftool_pod.html#advanced_options).
PD now uses this feature to pass the canonical ID of a pdImage object to
ExifTool, and when we are finally able to retrieve ExifTool's completed
data - regardless of VB's interference - we can always successfully
parse out those unique ID values and reconstruct metadata accordingly.

This is great news, because I think it means I have FINALLY solved the
bizarre and unpredictable problem where VB randomly postpones processing
of WM_TIMER messages, which breaks our connection to ExifTool and not
just leaves the library instance stranded, but also prevents us from
successfully retrieving metadata for the rest of a session.

As an added bonus, this has also allowed me to remove the final
pause-and-wait-for-metadata check from the image load function, which
was sometimes necessary to work around the aforementioned unpredictable
delays in WM_TIMER messages.  As such, image loading performance should
now be much more consistent, regardless of an image's metadata contents.