rtapi: rename "sim" to "uspace"

.. no change in functionality is intended, but this reflects the intent
to ultimately change "sim" to being suitable for use with RTOSes that
provide a pthread-compatible API
rtapi: use defined(__KERNEL__) to test for kernel space

.. as opposed to checking SIM and/or RTAPI or RTAPI_SIM
configure: Change "sim" to "uspace", with fallout elsewhere
rtapi_app: setuid permissions
packaging: linuxcnc-uspace, not linuxcnc-sim
rtapi_app: do commands based on a callback

this will enable sim_rtapi_run_threads to work in a pthreads model too
rtapi: roll uspace_rtapi.c into rtapi_app.cc
rtapi: Drop never-used APIs

.. rtapi_task_set_period and rtapi_task_stop are never used.
rtapi: Introduce class RtapiApp and implementation Pth

.. which has virtual methods that might depend on the userspace
realtime system.
uspace: use POSIX scheduler priorities

.. which happen to be in the opposite ordering compraed to the old
sim/pth priorities, so the code for next/previous priorities also
changes.
uspace: Implement POSIX realtime

Some code adapted from the "ubc3" branch (harden_rt)

For SCHED_FIFO, using distinct priorities gives rate monotonic
scheduling.  For SCHED_OTHER (running without root privs), locks give
the same no-slow-interrupts-fast guarantee as pth did (a slightly
different guarantee than RMS, because it also prevents fast interrupting
slow).

One item not in "ubc3" hardening is cpu_dma_latency hardening:
    https://www.kernel.org/doc/Documentation/power/pm_qos_interface.txt

The default stack size is greatly enlarged due to crashes I encountered
calling rtapi_print_msg inside realtime code; fprintf apparently uses a
lot of stack.
uspace: detect realtime delays
uspace: get time in nanoseconds, not microseconds
uspace: get rid of use of GNU pth

Since we can now run on posix threads without SCHED_FIFO and provide
the necessary rate-monotonic guarantee, there's no reason to retain the pth
implementation.
uspace: lock and page in shared memory segments

It's not clear whether this is needed (mlockall should cover it), but it
can't hurt.
docs: Documentation changes for uspace
rtapi: Can we run with realtime guarantee?
uspace: Ask gcc for the semantics we want

I know that hm2 uses casts in a way forbidden by gcc without
-fno-strict-aliasing.  I suspect that there are places that depend on
wrapping semantics for signed arithmetic, such as in encoder wraparound,
which is what -fwrapv asks for.
rtapi: provide rtapi_io.h

.. which provides the full {in,out}[bwl] APIs, with and without
rtapi_ prefix.
uspace: implement dummy request/release region

.. in that they always succeed, but there's no effective prevention of
concurrent access to the same I/O ports by the kernel as there is in
kernel space.