all platforms: separate cpu_initclocks() from cpu_startclock()

all platforms: separate cpu_initclocks() from cpu_startclock()

To give the primary CPU an opportunity to perform clock interrupt
preparation in a machine-independent manner we need to separate the
"initialization" parts of cpu_initclocks() from the "start the clock
interrupt" parts.  Currently, cpu_initclocks() does everything all at
once, so there is no space for this MI setup.

Many platforms have more-or-less already done this separation by
implementing a separate routine named "cpu_startclock()".  This patch
promotes cpu_startclock() from de facto standard to mandatory API.

- Prototype cpu_startclock() in sys/systm.h alongside cpu_initclocks().
  The separation of responsibility between the two routines is a bit
  fuzzy but the basic guidelines are as follows:

  + cpu_initclocks() must initialize hz, stathz, and profhz, and call
    clockintr_init().

  + cpu_startclock() must call clockintr_cpu_init() and start the clock
    interrupt cycle on the calling CPU.

  These guidelines will shift in the future, but that's the way things
  stand as of *this* commit.

- In initclocks(): first call cpu_initclocks(), then do MI setup, and
  last call cpu_startclock().

- On platforms where cpu_startclock() already exists: don't call
  cpu_startclock() from cpu_initclocks() anymore.

- On platforms where cpu_startclock() doesn't yet exist: implement it.
  Usually this is as simple as dividing cpu_initclocks() in two.

Tested on amd64 (i8254, lapic), arm64, i386 (i8254, lapic), macppc,
mips64/octeon, and sparc64.  Tested on arm/armv7 (agtimer(4)) by
phessler@ and jmatthew@.  Tested on m88k/luna88k by aoyama@.  Tested
on powerpc64 by gkoehler@ and mlarkin@.  Tested on riscv64 by
jmatthew@.

Thread: https://marc.info/?l=openbsd-tech&m=169195251322149&w=2