Various path functions were not treating paths consisting of slashes
alone consistently. For example, the iterator-based accessors decomposed the
path "///" into two elements: "/" and ".". This is not too bad, but it
is different from the behavior specified by posix:
A pathname that contains ***at least one non-slash character*** and that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname.
More importantly, this was different from how we treated the same path
in the filename+parent_path functions, which decomposed this path into
"." and "". This was completely wrong as it lost the information that
this was an absolute path which referred to the root directory.
This patch fixes this behavior by making sure all functions treat paths
consisting of (back)slashes alone the same way as "/". I.e., the
iterator-based functions will just report one component ("/"), and the
filename+parent_path will decompose them into "/" and "".
A slightly controversial topic here may be the treatment of "". Posix
says that paths beginning with "" may have special meaning and indeed
we have code which parses paths like "net/foo/bar" specially. However,
as we were already not being consistent in parsing the "" string
alone, and any special parsing for it would complicate the code further,
I chose to treat it the same way as longer sequences of slashes (which
are guaranteed to be the same as "/").
Another slight change of behavior is in the parsing of paths like
"net". Previously the last component of this path was ".". However,
as in our parsing the "net" part in this path was the same as the
"drive" part in "c:\" and the next slash was the "root directory", it
made sense to treat "net" the same way as "net/" (i.e., not to add
the extra "." component at the end).
A comment here maybe in order. Should this behavior be true for both path styles?