Discovered due to a goofy git setup, the test system-headerline-directive.c (and a few others)
failed because the token-consumption will consume only the '\r' in CRLF, making the preprocessor's
printed value give the wrong line number when returning from an include. For example:
(line 1):#include <noline.h>\r\n
The "file exit" code causes the printer to try to print the 'returned to the main file' line. It looks up
what the current line number is. However, since the current 'token' is the '\n' (since only the \r was
consumed), it will give the line number as '1", not '2'. This results in a few failed tests, but more importantly,
results in error messages being incorrect when compiling a previously preprocessed file.
Should we only do this in the \r case? If I understand correctly, we're basically saying, if this is a CR, and the next byte is an LF, advance one more and do the pre-processor stuff.