Ability to provide line separators in `readline`

[elimelt]

What is the problem this feature will solve?

Sometimes jsonl files are written with \u2028 or other separators inline in string values. I'd be nice to have a way to work around things like this using readline without rewriting everything to escape values when said file disagrees about what a line end looks like.

For example, from RFC 8259

  Since JSON's syntax is borrowed from JavaScript, it is possible to
  use that language's "eval()" function to parse most JSON texts (but
  not all; certain characters such as U+2028 LINE SEPARATOR and U+2029
  PARAGRAPH SEPARATOR are legal in JSON but not JavaScript).  This
  generally constitutes an unacceptable security risk, since the text
  could contain executable code along with data declarations.  The same
  consideration applies to the use of eval()-like functions in any
  other programming language in which JSON texts conform to that
  language's syntax.

What is the feature you are proposing to solve the problem?

A new configuration option to specify either a regex or a collection of characters to match for line ends. We'd of course keep the defaults the same.

What alternatives have you considered?

Writing my own decoder/generator to do exactly what readline does, but with my own definition of a line separator

I don't like reinventing the wheel

Recombining partial JSON lines when parsing fails

This is pretty inefficient

[elimelt]

Happy to make a PR if this sounds reasonable!

This issue is sort of related to #22448