Ptracing may cause timer overruns, as the ptraced application cannot
go waiting for the current period in a timely manner when stopped on a
breakpoint or single-stepped. A mechanism was introduced a long time
ago for hiding those overruns from the application, while ptracing is
in effect.

The current implementation dealing with this case has two major flaws:

- it crashes the system when single-stepping (observed on ARM i.MX6q),
  revealing a past regression which went unnoticed so far.

- it uses a big hammer to forward (most) timers without running their
  respective timeout handler while ptracing, in order to hide this
  timespan from the overrun accounting code. This introduces two
  issues:

  * the timer forwarding code sits in the tick announcement code,
    which is a very hot path, despite ptracing an application is
    definitely not a common operation.

  * all timers are affected / blocked during ptracing, except those
    which have been specifically marked (XNTIMER_NOBLCK) at creation,
    which turns out to be impractical for the common case.

The new implementation only addresses what is at stake, i.e. hiding
overrun reports due to ptracing from applications. This can be done
simply by noting when a thread should disregard overruns after an exit
from the ptraced mode (XNHICCUP), then discard the pending overruns if
this flag is detected by the code reporting them
(xntimer_get_overrun()).