tp: fixed TP velocity target behavior

After fixing the last issue with tpGetRealTargetVelocity and
tpGetMaxTargetVelocity functions, the target velocity was artificially
limited to the cartesian vLimit, even for a rotary move. Now the target
velocity is no longer limited for this case. Furthermore, the
pre-calculated target velocity for spindle-synchronized motion is now
preserved (instead of being overridden by the cartesian limit).
uspace: RT-harden before handling commandline

Otherwise, as observed by dgarr, rtapi_app would crash when the first
hal command was 'loadrt hal_parport cfg="0x378 in"', which executes an
inb() in its setup code.
hal_ppmc: port to uspace
uspace: use rtapi_get_time to implement rtapi_get_clocks if necessary

On non-x86 platforms there may be no tsc-like time source available
(e.g., arm).  The UBC arm port chose to use the "perf" interface,
but on the Samsung Arm Chromebook, I found that both gettimeofday
and clock_gettime are faster: Over 100k back-to-back invocations,
clock_gettime and gettimeofday both take about 850ns/invocation, while
the perf implementation takes 1500ns/invocation.
rtapi_bitops: fall back to implementation based on gcc intrinsics
rtapi_vsnprintf: Fix float formatting for !IS_IEEE754
rtapi_vsnprintf: arm IS_IEEE754

.. this gives the right results, and in about half the time as measured
by the test.
hal: explain why the enums all have distinct values
hal: use rtapi_bool.h for the type underlying hal_bit_t
hal: use rtapi_stdint for the types underlying hal types
uspace: Allow debugging rtapi_app as root

e.g., with
    sudo env RTAPI_UID=`id -u` valgrind bin/rtapi_app
or
    sudo env RTAPI_UID=`id -u` gdb bin/rtapi_app
rtapi_app will be executed by root but use your normal user's UID to
create shared memory segments, etc.  Once rtapi_app is running, you
can communicate with it using `halcmd` as usual (not halrun; this would
report that realtime was already running).
uspace: Raise RLIMIT_RTPRIO or fail at hardening

On ARM, the iopl() call is skipped, and there's nothing else that cause harden_rt
to fail.  This went unnoticed on the Arm Chromebook where the RLIMIT_RTPRIO was 10.
On the Parallela (Linaro 14.04) the user has RLIMIT_RTPRIO of 0.

On this system, which I assume behaves the same as glibc pthreads on other systems,
every pthreads API call to set up a thread (including pthread_attr_setschedparam
and pthread_create) returned success, but the thread always exited without calling the
wrapper function in this situation.
latency-test: use awk for calculations

.. since mawk is 'Priority: required' and bc is not in the base system.
configure: Don't suggest --enable-simulator
hostmot2: Introduce queue_{read,write} methods

Some hostmot2 hardware, such as the ethernet-based 7i80, benefits
from batching reads and writes.  This will be done with the new queue
methods, queue_read and queue_write.

For reads, first a call to llio->queue_read with normal addr, buffer, and
size args are made for each read entry.  Then a final ->queue_read call
is made with addr=0, buffer=NULL, and args=-1.  The same happens for
writes.

Cards which do not benefit from batched writes need not implement the new
methods.  Instead, hm2_register will fill the slots with a function which
delegates to the traditional read method whenever the size argument is
not -1.
hostmot2: move watchdog I/O to the read function

On ethernet-connected mesa hardware, each packet sent or received
has an appreciable amount of overhead.  By performing the watchdog
read during the regular tram read process, the number of packets per
servo period is reduced by one.

The hal watchdog function still exists and must be added to a thread
in order to detect that the watchdog has bitten.
hm2_eth: New driver for Mesa 7I80 ethernet cards