Handle rdtscp

rdtscp has a bunch of benefits for measurements (stay tuned for more
commits), but it only works on more recent x86 hardware, and doesn't
work on my old core2 development machine running qemu.

x86 will now catch the rdtscp invalid opcode trap and fake the command.
This will not give accurate numbers for measurement.  During boot, look
for whether or not RDTSCP is supported if you are curious.

In the future, we could have a flag that replaces rdtscp calls with
rdtsc at compile time, if someone wanted more accurate measurements on
older hardware.  For now, I'm not too concerned with those older
machines when it comes to measuring performance.
UINT64_MAX and friends available in the kernel
Changes rdtsc serialization methods

In short, use lfence;rdtsc; instead of cpuid;rdtsc.  For the long
version, read the info at the beginning of k/a/i/rdtsc_test.c.

Also, this will attempt to detect whether or not your hardware has any
issues preventing the reliable use of a TSC.  This includes not having
an invariant TSC, as well as getting SMI interrupts.  Again, read
rdtsc_test.c
Reworks timing infrastructure (XCC)

All of the old timing training stuff is moved out of kernel headers, and
is more in line with the recent TSC knowledge.  People can still use
stop_ and start_timing as convenience wrappers around
read_tsc_serialized().

Remove /ros/time.h from your cross compiler's kernel headers.  For
instance, for x86, rm YOUR_XCC_LOC/i686-ros/sys-include/ros/time.h.
Export timing overhead via procinfo (XCC)

You need to rebuild absolutely everything.  In addition to the cross
compiler, you also need to rebuild any out-of-tree apps, such as busybox
or Parsec benchmarks.
PXELINUX booting configs

Feel free to use my PXE make target (for those of your with access).
x86: changes LAPIC timer divisor to 32

Seems like a reasonable choice.  128 wasn't working on c89, since the
bus was so slow (100MHz) that we couldn't express 1 usec.  We could
allow some runtime setting/resetting, but 32 should be fine for anything
we need.
x86: handle overflow when setting the lapic timer

Note that if you have a long-running alarm and a short periodic alarm
that goes off frequently, the long-runner will continue to be reset
every time the periodic runs off.  For a brief moment, the long-runner
will be the next up, which will cause an overflow calculation, til the
periodic resets itself (depending on the nature of the periodic reset.
The ksched does the reset outside of the handler, for instance).