This closes issue haskell#13.

The changes can be summarized as
updating `findEOL` to look for "\r\n" in CRLF mode
and updating the logic of `haveBuf` to resize the buffer
according to the size of the newline.

Additionally, tests were added to verify that both
`hGetLine`s produce the same behavior.

Some of the edge-cases to worry about here include

* '\n' still counts as a line end.

    Thus line endings' length vary between 1 and 2 in CRLF mode.
* "\r\r\n" can give a false-start.

    This means you can't always skip 2 characters when `c' /= '\n'`.
* '\r' when not followed by '\n' isn't part of a newline.
* Not reading out of the buffer when '\r' is the last character.

The old test had wrote a special file filled with strange line endings.
Now that there is a reliable,
and consistent property test available for hGetLine,
this code can be removed at little cost.

… bug.

On Windows, the test data would be written using the platform newlines.
This means that any lone \n would become a \r\n.
The consequence is that the property would fail to test the
implementation on linux line endings when developing on windows.
The fix is to set the newlineMode to noNewlineTranslation before
writing the test data.

The variables were renamed to make boolean correspondance clearer.
Also, True was changed to CRLF in order to get QuickCheck to
try shrinking from CRLF to LF if possible.