Fix timing of EOMtheEMSrunner

[marcoaccame]

This PR fixes false reporting of execution time overflow emitted by object EOMtheEMSrunner that we have observed when the system is highly stressed.

The reason of the false reporting was due to a race condition inside the RTOS function osal_system_abstime_get() which may return non-increasing time between two consecutive calls, thus generating negative delta time.

In doing so, I have also added support to a proper monitoring of min, max, average duration of the RX, DO, and TX phases of the runner. Now this feature is disabled. Ideally, it could be useful to let the xml file that specifies the duration RX, DO, and TX phases also specify whether or not to activate this monitoring and the frequency of its reporting.

Some more about the RTOS improvement.

In osal, we measure system time in units of $us$ (but also the $ns$ are available). We achieve that by adding two contributions. The tick time of the RTOS that is typically at 1 $ms$ granularity and is incremented by the SysTick_Handler() gives the coarse resolution. The content of the STCUR register that counts down from its reload value to zero gives the fine resolution.
The combination of coarse and fine values are done inside the SVC_Handler() that has a higher priority than the SysTick_Handler(). In rare cases it may happen that the SVC_Handler() is called to get the system time but in the meantime the STCUR register goes to zero and set the SysTick_Handler() pending. In this case it is correct to add +1 to the tick count. Failure to do that results in a system time that can be wrong of 1 $ms$ so delta times can be wring by +1000 or -1000 $us$.

This PR fixed that.

Mergeability

I have tested the new feature on a dedicated setup with a nasty test harness and partly on iRonCub robot running at 1kHz reporting rate, so I believe that we can safely merge.

Associated PRs

We also have new binaries for ems, mc4plus, mc2plus, amc:

• amc v2.6, ems v3.92, mc2plus v3.72, mc4plus v3.93 icub-firmware-build#153