I also found out that the noise in the lighhts was coming from the USB
debug interface. For whatever reason it doesn't appear that the spi pins
are not well isolated from the debugger noise so unplugging and running
off one power source works pretty well.

I finally got a stable red/green pattern to show up on the LED strip.
Unfortunately I had to do this manually because my driver is broken. No
Dma, interrupts or drivers, but manually writing to the spi bus.

Currently the driver assums the data sheet doesn't lie and inflates each
bit 3:1 so a 1 is a 110 pattern and a 0 is a 100 pattern. This should be
well within the tolerances at 2.5Mhz, but alas it's not.

I figured out that it's better to inflate each bit to a 4:1 ratio so a 1
is a 1100 pattern and a 0 is a 1000 pattern. This appears to produce
cleaner results.

Bitfields are officially stupid. Bizzarre behavior was found in how the
bitfields integers were overflowing and causing other members to change
value, causing really screwy behavior. In addition, with the discovery
of 48k being available to the heap, a 12-bit value was no longer
sufficient to define the size.

I rewrote parts of the kalloc code to allow a generic size for the
kalloc header because now it'll require 2 words per block allocated,
and who knows what size the header will be on different platforms
with more memory.

Unfortunately, the second word of the header consists only of the "used"
bool. Because I wish to keep alignmennt with 32-bit words, 31 bits are
"wasted." However, these bits are used as a canary value to detect
heap corruption, so they're not completely wasted.

Also, testing was broken since adding the huge amount of platform
dependent code for doing system calls. These dependent parts were
put under a macro guard so they don't interfere with the x86 testing.