rtapi: introduce rtapi_next_handle()

This provides a unique integer ID for all sorts of objects. This ID is needed
to distinguish objects in the remote case where it is ineffcient to use
strings.

Using addresses as ID's will not work in the general case since these
will not necessarily be unique over an instance lifetime, due to
reclamation of memory of destroyed objects.

The id counter is updated with an atomic operation, and resides
in the global segment.

Replaces the current muted-protected next_module_id() method.
rtapi/shmem: improve error message
rtapi/support: set pid tag for logging early

this avoids the case where a log message is tagged with pid -1 in the
startup phase.
ulapi_autoload: reduce log noise
ulapi_main: printf warning correction for size type
rtapi/xenomai: improve error messages
rtapi/shmem: API change to retrieve shm segment size

An omission, but a consequential one.
rtapi/app: introduce procfs thread creation API

This enables rtapi_app to create RT threads for kernel threads flavors
without the need of the threads module, and more felxible.

rtapi_compat.c: fix default xenomai flavor selection logic

no point in choosing xenomai-kernel over xenomai-user
rtapi_app: rework as a flavor-independent RT demon, offering a zmq/protobuf RPC API

This commit folds all processing of RT components regardless of thread
flavor (kernel or userland) into interaction with a single demon,
rtapi_app.

Interaction with rtapi_app changes from the arcane unix domain socket
interface to use zeroMQ/protobuf interaction; for a description of
message formats see the rtapi_message.proto file. Also, rtapi_app is
assumed to be a demon proper, i.e. started upon realtime start.

For userland thread flavors, the flow is unchanged - RT components are
handled with dlopen() and entry points called via dlsym(). Also,
userland RT threads run in the context of rtapi_app.

For kernel thread flavors, rtapi_app just calls the module helper to
insmod the appropriate kernel module as directed by rtapi.ini. Kernel
threads remain in-kernel; however a newthread() interface is
introduced which works identically for userland and kernel threads, in
principle obsoleting the threads module.

In the userland RT threads case, newthread just starts a thread
through the appropriate HAL library API.  For kernel threads, a
procfs-based API is used, but the differences are hidden to the using
code - which is expected to use the rtapi_message API.

Shutdown:
rtapi_app records a module loading order, and on shutdown
unloads modules in reverse loading order. This was so far unspecified
behavior.

Background timer:
There is a background periodic timer which checks
fro rtapi_msgd (needed for logging), and potentially other periodic
tasks. See s_handle_timer(), which runs in a non-RT context.

Sockets use:

Since using code for the rtapi_app RPC interface is (for
now) assumed to run on the RT host, and for security considerations,
no remote socket API is offered. Instead, zeroMQ unix domain sockets
are used (ipc://...). The socket path name is derived from the
instance UUID, so any client is assumed to connect to
"ipc://<dir>/<rtapi_instance>.rtapi.<uuid>" (see ZMQIPC_FORMAT). This
affetcs primarily halcmd, and the new RTAPI cython bindings.

The "_rtapi" service currently is not announced via zeroconf, as deriving
the IPC URI from the (known) UUID is trivial.

UUID:
The instance UUID designates a running RT instance, and enables
disntinguishing several instances when instances are announced with
mDNS/zeroconf. The instance UUID necessarily ahs to be unique, and is
retrieved from the ini file specified in getenv(MACHINEKIT_INI), which
defaults to /etc/linuxcnc/machinekit.ini.
rtapi: adjust Submakefile

build rtapi_app for all flavors now

all module loading / unloading now goes through rtapi_app regardless
of userland/kernel threads flavors
rtapi_msgd: revamp
hal library: move to hal/lib subdirectory
hal library: revamp
halcmd: revamp

ping rtapi_app before going ahead with hal_init()

this closes a race condition where hal_init() would be called
before rtapi_app is done

default to IPC socket to talk to rtapi_app
use MACHINEKIT_INI

more secure, faster, and less fluff for service discovery
detail the error message.
halsh: retrieve MKUUID from MACHINEKIT_INI

since it uses halcmd objects to connect to rtapi
http/webserver: www root directory
webtalk: websockets/JSON <-> zeroMQ/protobuf bridge
haltalk: remote access and monitoring of HAL objects
machinetalk/nanopb: import version 0.27

nanopb_generator.py - adapt to machinekit nesting structure
+    #import proto.nanopb_pb2 as nanopb_pb2
+    #import proto.plugin_pb2 as plugin_pb2
+    import nanopb_pb2
+    import google.protobuf.compiler.plugin_pb2 as plugin_pb2
machinetalk/lib: fold various support functions into libmtalk.so

zeroconf, logging, protobuf utility code, avahi/czmq poll support, json/pb
conversion, ini helper