fix: CRLF newline handling and error span rendering

[metalurgical]

Previously, CRLF was treated as two newlines, causing incorrect line numbers, extra blank lines, and misaligned spans on Windows.

• treat CRLF as a single newline
• use consistent newline handling for line/column calculation and display
• fix trailing space rendering on empty lines
• preserve UTF-16 column alignment and span rendering
• Handle lone CR for current lexer behavior.

[metalurgical]

resolves #261
closes #261

[KyrylR]

#257 was merged, could you rebase pls

Also, have to ask you to narrow down the changes to CRLF only due to the reason that the lexer is limited to the LF/CRLF/CR (\n, \r\n, \r), though I do not see a reason to support CR, as it seems a legacy thing

[apoelstra]

ab4848a needs rebase

[metalurgical]

#257 was merged, could you rebase pls

Also, have to ask you to narrow down the changes to CRLF only due to the reason that the lexer is limited to the LF/CRLF/CR (\n, \r\n, \r), though I do not see a reason to support CR, as it seems a legacy thing

Has been narrowed to an explicit check instead of via is_newline().

[KyrylR]

Need to take a deeper look, there could be an issue with lexer that still uses .padded(), and Chumsky treats \r as whitespace there, so lone-\r input is still accepted

[metalurgical]

Need to take a deeper look, there could be an issue with lexer that still uses .padded(), and Chumsky treats \r as whitespace there, so lone-\r input is still accepted

I suspected CR still needed to be handled. So in this instance should it be erased or treated as a newline?

[KyrylR]

Not sure if we ever fallback into this, but let's proceed with restoring handling of bare-\r recognition inside next_newline()

Also could you leave a short comment that this is compatibility with current lexer behavior, not a statement that CR-only files are preferred?

I believe we can add those two tests:

#[test]
fn display_with_cr_only_newlines() {
    let file = "let a: u8 = 0;\rlet b: u8 = 65536;";
    let error = Error::CannotParse("number too large to fit in target type".to_string())
        .with_span(Span::new(27, 32))
        .with_file(Arc::from(file));

    let expected = r#"
  |
2 | let b: u8 = 65536;
  |             ^^^^^ Cannot parse: number too large to fit in target type"#;

    assert_eq!(&expected[1..], &error.to_string());
}

#[test]
fn display_span_as_point_on_trailing_cr_only_empty_line() {
    let file = "fn main(){\r    let a:\r";
    let error = Error::CannotParse("eof".to_string())
        .with_span(Span::new(file.len(), file.len()))
        .with_file(Arc::from(file));

    let expected = r#"
  |
3 |
  | ^ Cannot parse: eof"#;

    assert_eq!(&expected[1..], &error.to_string());
}

[metalurgical]

Not sure if we ever fallback into this, but let's proceed with restoring handling of bare-\r recognition inside next_newline()

Also could you leave a short comment that this is compatibility with current lexer behavior, not a statement that CR-only files are preferred?

Not sure if we ever fallback into this, but let's proceed with restoring handling of bare-\r recognition inside next_newline()

Also could you leave a short comment that this is compatibility with current lexer behavior, not a statement that CR-only files are preferred?

Lone CR support was added back in for compatibility with current lexer behavior only.

The proposed tests were also added in.