Fix relocation of collection reference from source to target.
When given a reference such as href="../foo/", Guise Mummy seems to be regenerating this as href="../foo" without the ending class for collection URIs. Without having looking into this or done any further tests, this may have something to do with the file system path representation for directories, or it may be a general bug for collection artifact link targets.
This fixes the bug of a missing collection ending slash for a source reference that gets relocated to the target tree when the target does not yet exist.
It should be noted that regeneration of the navigation elements don't have any extra checks based upon target resource type, but they still result in the correct links because they are based on the source artifacts, which already exist. And then when they are relocated to the target tree, this bug fix ensures they are generated correctly as well.
A more interesting case would be if we have a link to a source resource that doesn't exist yet, but we expect it to exist in the target tree. This might be the case with the new blog generation feature, which might generate entries from some database or other set of files not already in the correct tree structure. A link to one of the blog entries would probably still work, as the the blog entry is not a collection, but a relocated link to the blog base path blog/ itself might not work, as the destination might not yet exist in the source path. Thus when phantom source directories come into play, we may need to revisit this for any similar bugs that relate to resources not yet existing in the source tree.
This seems to be occurring when relocating a page from the source to target directory, when the link target hasn't yet been generated in the target tree yet. Thus a link to foo/ which gets relocated to link to the …/bar directory, when …/bar hasn't been generated yet, will result in only bar. If mummification occurs again without cleaning, the link will be corrected to bar/ because now the bar directory exists in the target tree.
We need to have some way to specify that a target link should be in collection form regardless of whether the target path actually exists (yet). One way would be to see if the sort path is a directory. There are two problems with that: one is that we may not always have access to the source path in the context of generating the link, and the other is that the source path itself may not exist either (such as a default index.xhtml file).
The more semantically correct approach seems to be to check to see if the target artifact is a CollectionArtifact; if so, it is guaranteed to be identified by a collection URI. This includes DirectoryArtifact, the most common case.