Add support to read lines longer than 1023 bytes

[arvidjonasson]

This pull request includes changes to improve the handling of empty byte sequences in kk_bytes_cat and the reading of lines from standard input in kk_os_read_line.

Enhancements to kk_os_read_line function:

• Added support to read lines longer than 1023 bytes. Achieved by concatenating 1024-byte chunks until new-line or EOF is reached.
• Fixes problem How can I read a single line of text that is longer than 1023 characters? #571.
• Remove redundant call to strlen by allocating string with kk_string_alloc_from_qutf8n instead of kk_string_alloc_from_qutf8.
• Other small improvements.
  (kklib/src/os.c)

Improvements to kk_bytes_cat function:

• Added checks to handle cases where either of the byte sequences is empty, such that the function returns the non-empty sequence and drops the empty one. Leads to an early return in these cases.
  (kklib/src/bytes.c)

Considerations

• Runtime for kk_os_read_line can degrade to O(n^2) for extremely long lines. However, this seems very unlikely, and I believe this to be a lesser issue than lines being incomplete for lengths >1023 bytes. To solve this we would have to scale buf by a factor >1 for each iteration in the loop, which can not be done safely on the stack. Thus it's hard to find a balance between solution complexity, constant overhead and algorithmic complexity. My approach prioritizes solution complexity and constant overhead as it stays true to the previous approach. An approach prioritizing solution complexity and algorithmic complexity can be achieved using the POSIX/Dynamic Memory TR getline(3) function.

[daanx]

Thanks for the PR -- looks good :-)

[arvidjonasson]

Thanks for the review!

I submitted a new version of kk_os_read_line. This should answer your concerns about it and improve the code quality.
Please send suggestions / concerns :)

[daanx]

Thanks for the quick update -- I'll take a look soon. These things always turn out to have surprising edge cases or portability concerns.