Huge metadata/ExifTool overhaul

Fixes #108.

This update would not have been possible without this excellent user
control from vbforums user "dilettante":

http://www.vbforums.com/showthread.php?660014-VB6-ShellPipe-quot-Shell-with-I-O-Redirection-quot-control

Thanks to it, all ExifTool interactions are now asynchronous.  When an
image is loaded, ExifTool is spawned in a separate thread, which allows
it to process metadata in parallel to PD's own image load process.  When
the image load is complete, PD reads the contents of stdout to retrieve
ExifTool's metadata parsing, meaning there is no longer a delay when
retrieving image metadata.

Similarly, when saving an image, after the image file is written,
ExifTool's metadata embedding is separately initiated, allowing the user
to continue working without waiting for it to finish.

Only one ExifTool instance is created during each session, meaning we no
longer have to endure painful overhead each time ExifTool is initiated.
I have not moved ExifTool's initial load to the program load phase (it
currently initiates when the first image is loaded), but will look at
doing so.

A number of metadata-related preferences have been removed as part of
this commit.  It is no longer possible to have PD completely copy over
existing metadata from an image, regardless of relevance.  I now force
metadata to be rewritten according to spec, and PD will always remove
invalid tags and junk like metadata padding (if not absolutely
necessary).  Tags will also be sorted into preferred categories, which
has proven beneficial while working with sloppy files that have
mismatched data in differing tag groups.

Also, there is no longer a preference for when to load image metadata.
Metadata is always loaded with an image, and short of disabling ExifTool
entirely, it is no longer possible to avoid this.  (Though there should
be no reason to avoid it, as the previous horrific time delays have
finally been solved.)