Event timers

[Alexander Motin]

Hi.

You should agree that event timers code we have now (hardclock,
statclock and profclock source) is real mess. The code is completely
machine-dependent, many times duplicated (I have found 4 or 5 equal
implementations and many more trivial ones), very tangled and
inflexible. While it is acceptable for some platforms with single
interrupt source running on hz, x86 with it's many different timers
definitely doesn't look good. So I've decided to clean it.

I have defined several points on that way:
1*. clean low-level timer drivers from unrelated stuff,
2*. make some common code machine-independent,
3. write common driver API for event timers (alike to one we have now
for time counters) to make adding more drivers possible,
4. add support for HPET as event timer in addition to time counter,
5. add support for timers in one-shot mode (LAPIC and HPET).

I have already committed first patch (r208494) for points 1 and 2. I
have added two new MI functions timer1clock() and timer2clock(), which
implement division of incoming interrupts from one or two sources per
CPU between calls to hardclock(), statclock() and profclock(). Now MI
code should just provide interrupt sources calling respective functions
on every tick and set timer1hz and timer2hz variables, reporting their
frequency. If only one interrupt source present, timer2hz should be set
to zero. Provided functions will divide these interrupt rates according
to already existing hz, stathz and profhz variables.

I have updated all x86 timers to use new KPI. Now these drivers look
better, getting closer to wrapping into abstract API.

Other architectures should not be harmed as all legacy methods are still
completely functional. Though update would give benefits in either
better functionality or at least more clean code.

-- 
Alexander Motin