Bring all available APs to Long mode; or: SMP!!

Boot up all logical CPUs and make them execute threads of the 'idle'
program. Aren't four CPUs that do nothing better than one? (Actually, the
BSP doesn't go 'idle' but spin-waits; sorry, my fault but I want to commit
now ;-))

I stripped down the code enormously by testing and removing what didn't
change the correct result :-) OK, the MINIX be-really-sure strategy was
clearly too much code but I also removed the BIOS and CMOS initialisations
which could possibly later bite us. I have no idea if skipping this step is
safe but the SIPI also gets a destination to jump to which is apparently the
only needed thing...

The Intel-devised 200 us sleep to let the APs get themselves done with the
IPI worked but they were dog slow with the emulator and 8 cores a 2 HTs. I
followed Pure64 and polled the ICR Delivery Status register which makes it
marginally faster. I eye-on-watch measured that's less than half a second.
OK, it's not fair to load qemu with 16 endlessly spin-waiting threads and
expect to measure milliseconds correctly. I can't really tell if it's worth
the trouble so I leave both approaches in and use the polling for now
because my stomach tells me that it tends to be faster.

Writing the AP boot code wasn't too difficult. However, loading it to 0x8000
was a bad idea because apparently it did overwrite the gdt :-) Thanks to the
error code for GPF and qemu's logging this wasn't hard to detect. The code
is now copied to 0x7000 where it won't overwrite too much - if at all.

As for the 0xf0000 problem: I must have seen a zero too much or something in
that map.

You can nicely watch (with a slow enough emulator) how the APs start up and
tear down to long mode where they write their CPU number to screen. Note
that this happens synchronously as other processors are either not awake or
busy-wait already at the end.