Applying a single gravity value for anticipating on all timer shots -
regardless of what the issuing timer is being used for - falls short
of considering the proper latency attached to the context. This leads
to poor tuning, with either negative latencies (i.e. early shots)
observed on measuring the jitter for irq handlers, or higher latencies
than expected for user-space threads when using too optimistic
(i.e. small) clock gravities.

Typically, the distance between the core clock handler and the
associated kernel-based handler the former calls, is much shorter than
what has to be traversed for switching in a kernel thread. It is even
shorter than the latency incurred for switching a user-space thread
from the core clock handler.

To solve this, we differentiate timers on the final context they
activate, between irq(handler), kernel and user threads, using the
appropriate gravity value when planning for the next shot, on a
per-timer basis, instead of using a single per-clock gravity as
previously.

Two additional contexts (irq and kernel) are added to the clock
gravity settings. The user can pass a hint to xntimer_init() for
indicating which kind of context will be activated by this timer (see
XNTIMER_[IKU]GRAVITY).

There are side-effects for this change on the procfs support:

- the information previously available from the xenomai/timer entry is
  now obtained by reading xenomai/clock/coreclk. In addition, the
  clock gravity values are reported.

- the former contents of xenomai/clock/* entries (i.e. the list of
  active timers running on the associated clock) is now available from
  the new xenomai/timer/* entries, also indexed on the clock name.

Writing to an entry under xenomai/clock/* can be used to change the
gravity values of the associated clock.

/* change the user gravity (default) */
echo 3000 > /proc/xenomai/clock/coreclck
/* change the IRQ gravity */
echo 1000i > /proc/xenomai/clock/coreclck
/* change the user and kernel gravities */
echo "2000u 1000k" > /proc/xenomai/clock/coreclck