communications: allow any non-null char send_command -> receive_command

Previously, we used a newline to mark the end of the message sent from
send_command(), which restricted the characters we could send across
(ie, we couldn't send a newline). This was a new limitation of sdorfehs
that was not present in ratpoison. In particular, "ratpoison -c echo"
was instrumented to be able to handle newlines in the message and draw
variable-height windows to show them (for example, "ratpoison -c
$(ncal)".

After the sdorfehs change and switch to unix domain socket, sdorfehs now
uses a newline to mark the end of the command, and will therefore
silently truncate the sent message at the first newline.

This limitation can be removed; it's safe enough to go until we see a
NULL because it's always there:

- there's only one caller of send_command(), ie main() coming from
"sdorfehs -c" processing; since that comes from the program's
argument vector, we know it will always terminated by a NULL itself

- our buffer was fully cleared at entry, so a small read will be
terminated by the trailing initialized bytes

- if the sender exceeds our buffer size, it's already handled in the
code by checking that we reached the end and aborting with a
"bogus command length" message (this was verified by stepping
through with gdb using 'sdorfehs -c "$(ncal 2024)"')

Note that the end of buffer content comes before we might expect it
because the full command string is included: the "interactive" byte, the
command word itself, and the entire argument string.

Note also that code on both ends (sender and receiver) has to take
special care with the first byte, because it determines if the command
is interactive.

While this patch removes the newline limitation, this receiver code is
still limited by being able to use only a single buffer, and doing
character-at-a-time reads therefrom. To be addressed in following
commits.