file-system and locators cleanup

[cgay]

Some issues I've noticed while doing a bit of work on the System library:

• expand-pathname is totally different on Unix and Windows. Unix only expands "~" and "~user" in the first element of a relative path. Windows only calls GetFullPathnameA, which doesn't appear to do anything related to user expansion and is also the function called to implement resolve-file.
• file-type on Windows will never return #"link". Windows has had symlinks since Vista. Looks like we can use FILE_ATTRIBUTE_REPARSE_POINT to determine whether a file is a symlink.
• Comments in rename-file piss and moan about having to check if the destination exists. We might be able to avoid that if RENAME_EXCL is commonly supported.
• Similar comments in copy-file. See copy-file is implemented by shelling out to /bin/cp on Unix platforms #1649 and check for something similar to RENAME_EXCL.
• Define constants for the supported file properties. Easy to misspell #"writeable?", particularly easy to leave off the ?.
• do-directory(fn, dir, descend?: #t, match: glob("*.dylan")) would be nice rather than having to recurse manually. Or could be a new function, scan-directory or something.
• directory-empty? returns true if the directory doesn't exist. Why is it not an error?

[cgay]

RE: expand-pathname...

On Unix I'm removing all calls from other file-system functions to %expand-pathname because "~" and "~user" are valid pathnames and so expansion (or not) should be the user's choice.

On Windows, as noted above, %expand-pathname is basically resolve-locator. As noted in Windows docs some file APIs require a full pathname and some don't, so I don't feel comfortable removing the calls to %expand-pathname there. It sort of looks like the Unix and Windows implementations had different ideas about what that function should do.

So instead, on Windows I'm going to make expand-pathname a no-op (for now at least) and change callers of %expand-pathname to call a differently name internal function (say, %get-full-path) and leave a comment. Later on we can exhaustively survey the other APIs we use and see if they need a full path or not.

[housel]

I think a case could be made that expand-pathname means "expand a pathname abbreviated according to the local OS conventions into a non-abbreviated name". On Windows, there's not a ~user convention, so the only abbreviation convention is the 8.3 pathname shortening, so it makes sense that expand = unshorten. On POSIX systems ~user is the only abbreviation convention, so it makes sense that expand = substitute user home directories.

The automatic calls to expand are indeed something that should never have been added; it should absolutely be the user's choice.

[cgay]

I think a case could be made that expand-pathname means...

I've updated #1735 to reflect that.