Fix unpacking compressed archive when owner doesn't have 'rw' permission on some files/directories

[pjbriggs]

Fixes an edge case when an compressed archive has been created from a source with some files and/or subdirectories don't have read-write permission for the owner.

It is possible for these archives to be created if the owner is different from the user making the archive. These are valid archives as they can be unpacked and verified directly using the cp, tar and md5sum command line tools, however the unpack functionality of the archiver has problems handling them - depending on which files and directories are missing the permissions it may either fail to unpack completely, fail to set permissions from the archive, or fail to verify checksums.

This PR contains a number of updates to the unpacking functions and methods to address this:

• The functionality for setting permissions and timestamps has been extracted from the core unpack_archive_multitgz function into a separate function set_attributes_from_archive_multitgz (which also allows the invoking function to specify whether to update either one or other of permissions and timestamps, or both together, or neither). By default setting of permissions and timestamps is no longer performed by unpack_archive_multitgz.
• The new set_attributes_from_archive_multitgz reimplements the setting of attributes so that files are handled in one pass and directories in another (this aims to prevent situations where the permissions could be set to remove read-write on a directory before its contents have been updated).
• The unpack method of the ArchiveDirectory class now defers setting of attributes until after verification (as neither permissions nor timestamps are checked), so that unreadable files and/or directories don't cause problems.

In addition the default behaviour of the unpack functionality has changed so that permissions on the unpacked files and directories are not set from the archive (this is matches the default behaviour of tar for non-root users). This required a change to the way that directories are extracted from archives in the unpack_archive_multitgz function (to address an apparent inconsistency in how tarfile.extract() handles permissions on directories).

A new option --copy-permissions has been added to the unpack command in the CLI which forces the permissions to be restored from the archived versions (i.e. the behaviour of unpack prior to this PR).