readline: add unicode line separator option

[scarab-systems]

Fixes: #22448

This adds a unicodeLineSeparators option to readline.createInterface() and readlinePromises.createInterface().

By default, behavior is unchanged: \u2028 and \u2029 continue to be treated as line endings. When unicodeLineSeparators: false is passed, readline only splits on CR, LF, and CRLF, allowing formats such as JSONL to preserve Unicode line and paragraph separators inside record contents.

Tests added/updated:

• ./node test/parallel/test-readline-line-separators.js
• python3 tools/test.py --shell ./node test/parallel/test-readline-line-separators.js
• make lint-js LINT_JS_TARGETS="lib/internal/readline/interface.js lib/readline.js test/parallel/test-readline-line-separators.js"
• make lint-md LINT_MD_FILES="doc/api/readline.md"

[aduh95]

I wonder if a boolean is the correct way, or if we should instead let the user define their own list of separator as suggested in #60606 (comment)

[scarab-systems]

That makes sense. I agree a boolean may be too narrow if we are adding a new API surface.

Would an additionalLineSeparators option be a better shape here? My thinking is that \n, \r, and \r\n should remain the fixed readline line endings, while this option controls only the extra separators. The default could preserve current behavior with ['\u2028', '\u2029'], and JSONL users could pass [] to preserve U+2028/U+2029 inside records.

I can rework the PR in that direction if that seems aligned with what you had in mind.

[aduh95]

I agree that reverting back to only \n/\r is likely a goal, though that would be a semver change, so we'd better land that separately. We could add a option lineSeparators that would take either a string, a regex, and maybe some magic values (e.g. Symbol.for('nodejs.readline.classic'), Symbol.for('nodejs.readline.unicode'))

[scarab-systems]

That makes sense. I can rework this PR away from unicodeLineSeparators and toward a lineSeparators option, while preserving the current default behavior here and leaving any default revert to a separate semver-major change.

For this PR, I’ll aim to keep the immediate problem covered by two built-in modes: current Unicode behavior by default, and a classic CR/LF/CRLF-only mode for JSONL-style inputs. If you think custom string/RegExp separators should land in the same PR rather than as a follow-up, I can shape it that way too.