comps/rtfault: generate realtime faults on purpose for testing

mainly for testing rtmon.comp
RT fault handling: test program to exercise rtmon.comp

This shows how custom behavior on RT faults can be implemented
This hal script will raise rtmon.estop and automatically clear it after
one second.
xenomai.c fixes
xenomai-kernel: add missing HAVE_RTAPI_TASK_SELF_HOOK
xenomai-kernel: add rtapi_backtrace_hook()
rtapi_task.c: remove deprecated comment
rtapi_msg.c: remove unused file
rtapi_support.c: switch to message ringbuffer, deprecate RTAPI_PRINTK
rtai-kernel.h: remove deprecated RTAPI_PRINTK
rt-preempt.c: correct printf warnings
rtapi_msgd: comment, add poll timer decay scheme
rt-preempt.c: add thread name to RT fault message
rtapi: delete unused files
rtapi/flavor: remove deprecated #include
rtapi/shmdrv: tone down logging
rtapi/shmdrv API: add shm_common_init() and shm_common_unlink()

shm_common_init() initializes the common shm API

shm_common_unlink() provides a means to shm_unlink() an entry from /dev/shm/linuxcnc-* if
using Posix shm when it is known that further attaches to a particular
shm segment may not happen (eg during shutdown)
rtapi/modules: move % split rtapi_assure_module_loaded()

make this two functions:

a test - is_module_loaded(modname)
a module loading function: load_module(modname,args) (currently unused)
rtapi.h: add comments
rtapi:  switch to unified startup sequence

This is a major change on how startup and shutdown works. The principles are:

1. If the shared memory driver is to be used (kthreads, optional for uthreads),
then insmod that first during startup.

2. The next step is to start rtapi_msgd, which creates and populates the
global shared segment which all other entities (rtapi_app, RT modules,
user HAL comps) attach to. This segment carries vital parameters like
thread flavor, loglevels, and in particular the error message ring buffer
through which all rtapi_msg* logging goes. This is also the place where
environment autodetection happens; any startup validation should go here.

3. kthreads: rtapi.ko attaches to the already existing global segment, and
goes from there (note this is made possible only by the shmdrv module -
with other kthreads-specific methods it is _not_ possible to create a shm
segment in userland and then have a kernel module attach to it). The shmdrv
API supports a in-kernel method to attach a segment which was created out
of kernel.

4. Userland threads: rtapi_app attaches to the global segment, uses logging
level and flavor, and starts the RT environment by loading rtapi.so and
hal_lib.so; rtapi.so attaches to the global segment for use in the RT
symbol space independently from rtapi_app (note that rtapi_app and RT
modules do not share symbols and libraries).

5. ULAPI hal_lib: the hal_lib.c shared library constructor does all the
heavy lifting: attaching to the global segment, loading the proper ulapi.so
module, and pass in the global data segment address through the ulapi.so
ulapi_main() initialisation call.

6. rtapi_msgd remains running until realtime shutdown, and polls the
error message queue which all parties write to as needed, then wrting them
to syslog.

The only place where the global data segment is populated is rtapi_msgd(),
hence move init_global_data() there and out of rtapi_common.c.

hal_lib: simplify the constructor/destructor scheme - this was more
powerful (and complex) than needed.

Previously the startup order and creation sequence of shm segments was
rather different between flavors. This common flow is much easier to
understand and debug.
rtapi: remove unused get_global_handle() method