Convert the line endings manually since the parser is sensitive to the
trailing whitespace (the writing of the file will create a `\r\n` rather
than `\n`). This largely fixes the issues for Windows with the issue
that the processing of the file location is currently not properly
processing escape characters and results in issues.
In theory, it should be possible for `getStringLiteralIfNotInterpolated`
to process the literal segments with `getEncodedStringSegment` for each
segment and then return a literal value cooked. However, doing so will
require that the function return a `std::string` rather than `StringRef`
since the cooking means that we cannot simply provide a reference to the
SourceManager view.
GYB opens its inputs and outputs in text mode. This is a problem because the recommendation in Windows is to check everything out in LF mode to avoid breaking tests, so gybbing a file ends up converting LFs to CRLFs. That broke test/SILGen/magic_identifier_file_conflicting.swift.gyb.
Modify GYB to open its files in binary mode instead of text mode. This is a no-op everywhere but Windows.
Note that this change is incomplete: it’s somewhat difficult to switch stdin and stdout to binary mode in Python 2. I’ve added FIXME comments about this.
