Support for Unicode line termination characters

See https://github.com/microsoft/language-server-protocol/issues/376#issuecomment-1059398775

From @hgs3

Adding to my previous post: Obviously using code points is a non-passive change and would require a major version bump.
If the protocol goes that route, I wanted to make one other non-passive suggestion: Do not synchronize the client/server using "lines". The protocol defines '\n' (U+000A), '\r' (U+000D), and '\r\n' (U+000D U+000A) to indicate new lines. This is not conformant with the Unicode definition of line terminators. One could argue this isn't a problem because it's a protocol convention, however, at the very least, clarifying language needs to be added as to what should happen when a server/client encounters a Unicode line terminator not in the LSP (like Next Line, U+0085). Right now, it isn't clear if a client should strip them out or if a server should replace them with '\n', '\r', or '\r\n'. If a server submits the source code as-is to a Unicode conformant programming language tokenizer and a code point like U+0085 is present, then the line offsets will be desynchronized.

I would argue lines in general are not a good synchronization mechanism. I would recommend against enhancing the spec to include the Unicode line terminators, because it's always possible additional line terminators are added in a future Unicode revision. The correct way to synchronize Unicode text, making it Unicode version agnostic, and thus avoid client/server confusion is to use code point offsets and drop the concept of a line (and column) from the spec entirely. Ideally, version 4 of the LSP will focus on Unicode conformance and improving abstractions.

Start with the linked Language Server Protocol discussion and the current specification's definitions of line termination and position offsets. Determine whether the protocol should clarify Unicode terminator handling or replace line and column synchronization with code-point offsets; done requires an agreed specification change and versioning decision.