Draft: Look at diff for just using ticks in public kernel api

[kent-mcleod]

constraints that change:

• max/min budget/period constraints are much less because there isn't overflow issues in conversion between ticks and us
• System doesn't perform division operations. Division implementation for 64bit values doesn't have to be validated on each platform/timer frequency used.

build constants that need changing:

• CONFIG_BOOT_THREAD_TIME_SLICE
• TIMER_PRECISION
• ksDomSchedule.length
• CLOCK_SYNC_DELTA
• CONFIGURE_KERNEL_WCET

Runtime API changes:

• SC_Configure would take ticks
• consumed return value would be in ticks

[Indanz]

We already have a ticks version of TIMER_PRECISION: TIMER_OVERHEAD_TICKS. But those config values are constant and could be calculated at compile time. So it's really only SC_Configure that breaks the API.

[Indanz]

This is what MCS should have done from the start IMHO. Other than people getting the CLK_MAGIC and CLK_SHIFT wrong, the main problem with doing this conversion in the kernel is mostly on 32-bit platforms with a fractional MHz clock, where that approach just doesn't work because of overflows.