Added the ability to process streams that use CR or CRLF as newlines

[boenrobot]

Fixes #6

[SimonFrings]

@boenrobot thanks for looking into this, definitely an interesting solution 👍

I was thinking, what if there's the case a chunk ends with \r\n\r and the last \n is missing because it didn't fit. This would lead to the next message starting with \n and result in the parser failing to parse the whole message.

What do you think about this one?

[boenrobot]

Interesting edge case... I guess it should be safe to just remove the leading space from the buffer? I'll prepare a test and see if that addresses it.

[boenrobot]

I added a test case, and it seems like it passes.

And on closer examination, that seems to make sense thanks to the fact that empty lines in a message are ignored. The first message is cut at the second \r, and the next \n is treated as an empty line in another message, and that empty line is effectively skipped due to $name being false (since the line doesn't contain :). That way, the end result is the same.

[boenrobot]

I've reverted what I thought was a performance improvement in the building of the message, after doing some synthetic benchmarks, and added an "/S" flag to the regex, since the optimizations it's supposed to make are applicable exactly in scenarios like this one.

And I've squashed all commits into one, to not pollute the commit log.

[clue]

@boenrobot Thanks for looking into this, changes LGTM!

Looks like an excellent improvement over the current situation, we can also build on top of this if we find that a broken up CRLF shows up again!

Keep it up!