hal/comps/lowpass: make gain a pin

used in the remote HAL UI demo
Squashed 'src/machinetalk/proto/' content from commit db04f80

git-subtree-dir: src/machinetalk/proto
git-subtree-split: db04f801af90408de98d6f0f948495ffc4a8ef81
Merge commit 'fa2e378eeb25050e5a9ea76cae71788764fb73e9' as 'src/machinetalk/proto'
gladevcp/widgets: fix for HAL_ProgressBar
tests/build/header-sanity: skip generated C++ protobuf headers

those are named '*.h' but are actually C++ includes
docs/highlight: support protobuf highlighting
shmdrv api: be more resilient when opening the driver

sometimes udev can take a while to get its act together, so be patient
rtapi/bitops: add atomic add_and_fetch primitives
rtapi: spin out integer types into separate include file
rtapi: hexdump library function
rtapi/ringbuffer: introduce multframe ring buffer API

This matches the format and terminology of zeroMQ frames and messages.
Used to support uniform end-to-end messaging of zeroMQ message streams
to and from RT components.

(c) Pavel Shramove 2014, MIT license.
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.