Handling image files: prevent accumulation in template, jpeg orientation and template correction

As issues #23 and #38 already point out, the accumulation of image files in the template is undesired behavior. I propose these changes as a solution, beside some other minor improvements.

Since the proposed changes with issue #23 were rejected for not being backward compatible and because of the desired functional coding style, there was little room for a complete solution; the unique file paths do need to get across from `picture()` to `savedocx()`. Therefor I propose adding an extra parameter and return value to `picture()` and `savedocx()`, containing the unique image paths to be added to the docx file. The `imagefiledict` parameter is made optional because of backward compatibility. However, this does revert to copying the images into the template directory.
(I have taken the liberty to suggest a `PendingDeprecationWarning` when `picture()` or `savedocx()` are called without the `imagefiledict` parameter.)

The other minor improvements consist of applying the orientation information in EXIF data, if available, to the `xfrm` element, and the removal of an undesired relation in the template.