Due to the accumulation of rounding errors, using raw TSC counts for
measuring long timespans may yield (increasingly) wrong results.

In short, either we guarantee stable computations with counts of
nanoseconds, or with TSC instead, regardless of the clock source
frequency, but we can't provide such guarantee for both. From an API
standpoint, the nanosecond unit is definitely the best option as the
meaning won't vary between clock sources.

Avoiding the overhead of the tsc->ns conversion as a justification to
use raw TSC counts does not fly anymore, as all architectures
implement fast arithmetics for this operation over Cobalt, and
Mercury's (virtual) TSC is actually mapped over CLOCK_MONOTONIC.

Therefore, all TSC reading and ns<->tsc conversion services are
removed from the Alchemy API to prevent misleading results. Users
should measure timespans (or get timestamps) as counts of nanoseconds
as returned by rt_timer_read() instead.

The following calls are dropped from the API:

- rt_timer_tsc()
- rt_timer_ns2tsc()
- rt_timer_tsc2ns()

In addition, rt_timer_inquire() does not return the TSC count anymore.