Endangered I/O operations

[Simon Marlow]

I'm currently re-implementing GHC's I/O library, and I'd like to get
people's opinions on the following I/O extensions currently provided by
GHC - should we continue to provide them or not.

1. IOExts.hConnectTo

This was designed to be a way to have one handle automatically flushed
before we flush another handle (eg. outputting to stderr causes stdout
to be flushed first).  The current implementation has a number of
problems: errors and blocking arenn't handled properly when doing the
connected flush.  If no-one is using it, I'd like to get rid of it.

2. IOExts.withHandleFor

This is a cunning hack to allow you to temporarily redirect one handle
to another, like 2>&1 in shell speak.  I'm dubious as to whether it
works consistently - there's certainly not enough error checking in the
implementation, so if no-one is using it I'd like to drop it.

3.  IOExts.hGetBuf, IOExts.hPutBuf,=20
    IOExts.hGetBufBA, IOExts.hPutBufBA

These are the "non-blocking" versions of hGetBufFull, hPutBufFull etc.
I can't remember why we have both blocking and non-blocking versions,
although I distinctly remember implementing and documenting them :-)  If
anyone is using, or knows of a good use for, the non-blocking versions,
then I'll keep them.  Otherwise, I'd like to rename hGetBufFull to
hGetBuf, and similarly for the others.

Cheers,
	Simon