[stm32-ocm3] timers: tidy up define usages before starting work

before: about 20% too fast for most cases
clock_delay_usec: 500 * 200usecs, 9/10
test took 801.557779 vs expected 1000.000000, delta: 19.844222

clock_delay_usec: 5000 * 20usecs, 9/10
test took 818.652868 vs expected 1000.000000, delta: 18.134713

clock_delay_usec: 100 * 1000usecs, 9/10
test took 793.931007 vs expected 1000.000000, delta: 20.606899
[stm32-ocm3] Improve clock_delay_usec behaviour

It's now within ~1% for reasonable delays, and a little slow for shorter delays.

Test results below for the clock_delay_usec portion

500 * 200usecs
test took 1008.728981 vs expected 1000.000000, delta: 0.872898
5000 * 20usecs
test took 1074.591875 vs expected 1000.000000, delta: 7.459188
100 * 1000usecs
test took 1009.047031 vs expected 1000.000000, delta: 0.904703
cpu/arm/stm32-ocm3/clock.c: more efficient clock_delay_usec; tighten calculations

This commit picks up the original idea of waiting based on intervals of
the system tick timer alone. It improves upon it by using a more
accurate algorithm and by taking measures to limit the accumulation of
rounding errors, especially if operating with a very slow system clock.

It also removes the need to have systicks enabled when calling
clock_delay_usec.
Merge pull request #1 from frtos-wpan/better-clock

Improved version of clock_delay_usec
Merge remote-tracking branch 'karl/locm3'