RFD: deprecate permissions-related stuff in System.Directory

[Simon Marlow]

System.Directory has the following:

     Permissions(
	Permissions,
	readable,		-- :: Permissions -> Bool
	writable,		-- :: Permissions -> Bool
	executable,		-- :: Permissions -> Bool
	searchable		-- :: Permissions -> Bool
       )

     getPermissions            -- :: FilePath -> IO Permissions
     setPermissions	      -- :: FilePath -> Permissions -> IO ()

I propose to deprecate all this, in favour of using platform-specific 
functionality instead.  Here's why:

  * Most uses of `getPermissions` are wrong.  If you use `getPermissions` to
    predict whether a future operation will fail or not, then the right
    thing to do is to perform the operation and catch the failure exception.
    The result of `getPermissions` is immediately stale, and cannot be
    relied on alone.

  * The meaning of these operations on Windows is not clear.  Windows has a
    much more elaborate access control model than Unix.  For example,
    permissions can be inherited.  Windows' emulation of the Unix `access()`
    function doesn't support the execute bit, and only has partial support
    for the other bits.

  * There doesn't seem to be a good least-common-denominator for access
    control, so we should provide good platform-specific support instead.
    (one problem here is that we don't have good platform-specific support
    for Windows, yet).

These functions are hardly ever used.  I did a Google code search for 
setPermissions and aside from implementations of setPermissions itself and 
tests for it, I came up with:

  * copying permissions from one file to another.  This is used in the
    implementation of `copyFile`.  We can and should do this natively.

  * one use in Wash

  * some uses in old versions of Cabal, when installing files (Cabal now
    uses `copyFile`).

There are a few more uses of `getPermissions`, but as pointed out above, 
these are usually flawed.  In any case they can usually be replaced by 
openFile.

This isn't a proper proposal because I haven't written any code, but if we 
reach agreement in principle, I'll submit a real proposal.

Cheers,
	Simon