Drop usage of system clock in controller loop.

Internal trajectory representation is no longer parameterized on the system
clock, but on a monotonically increasing variable representing controller uptime
(the base is irrelevant, the important thing is that it's monotonically
increasing).

This solves the problem that if the system time changes during controller
operation, the result is a potentially dangerous discontinuity in the joint
commands. It's true that one should not perform abrupt time changes during
operation, and only do very small corrections (eg. NTP slew), but it stands
to reason (and to the principle of least surprise) that already queued
commands should not be affected by an external influence like a time change.

When a new trajectory command arrives, it will be immediately transformed to the
monotonic reference. In this way, system time changes affect only new commands
arriving _after_ the change, and not already queued ones.
Protect shared time data behind a realtime buffer.

Note: We're using the realtime_tools::RealtimeBuffer the wrong way around,
ie. we're writing from a realtime thread, and reading from a non-realtime
thread. The ideal solution would be to use a lock-free data structure.