nml: implement command queue with reliable reception

For a very long time, the way that UIs detected the reception and
completion of a command sent to task was based on a bad design: each
UI allocated serial numbers locally, and polled the stat buffer's
echo_serial_number for equality with the sent serial number.

Furthermore, the command channel was not a queue, so when two UIs
submitted commands at almost the same moment, it was possible for task
to receive only one of them.

Sascha's design converts all the command channels to queues (the .nml
file changes), adds consistent multi-client serial number generation to
nml "local", "phantom", and "shmem" transports, and modifies all in-tree
UIs to use these facilities to prevent bugs like the #395 lockup and
the #328 pause.

However, this may negatively affect out-of-tree UIs (which directly
talk to the NML protocol or NML library; ones that use python
linuxcncmodule will benefit from these changes), and distributed NML
setups (because the serial number generation does not work for the TCP
transport).

It also affects the ability of UIs to determine whether a submitted
command resulted in an ERROR response, because if another UI submitted
a later command, only its status (and not the previous command's status)
can be seen in the stat buffer.  This is probably OK, becuse for failures
like this one typically gets operator messages rather than relying on
the single success/failure flag in the stat buffer.

I tested this and it sure closes SF#395.  Sascha believed it fixed #328.

Closes: SF#328, SF#395

Based-on-patch-by: Sascha Ittner <sascha.ittner@modusoft.de>
Signed-off-by: Jeff Epler <jepler@unpythonic.net>