Add a prototype kernel-in-userspace.

I've been hacking on this for a few days, and finally managed to get
the "hello world" test case working.  To compile and run, simply run
"make && make test" in the new protokern directory, then run "./main
test/hello".

The current prototype kernel only supports one call via IPC, which is
the "console-print-line" call (IPC_CALL_CPRINTLN).  Obviously, more
will have to be added, but much of that will depend on the API Firefox
presents us.  The architecture of the kernel may also have to be
reworked slightly depending on this API.

There is an added caveat to this kernel w.r.t. how Zoog actually
should work, from my understanding: the register %ebx needs to be set
to point to a function table before running any pre-compiled Zoog
programs.  However, the current kernel uses execve to start a new
process, which blows away all memory mappings that existed before the
execve, so whatever value we may stick in %ebx will not only be
useless, but will also probably be clobbered by the syscall.  So, this
execve call will likely have to be replaced with some fancy footwork
with mmaping pages from an executable into memory, then mapping a page
for the function table, then jumping to the entry point of the Zoog
executable.
Zload bootstrapping program "in-place", some reorganization.

Since the Zoog ABI requires that ebx point to the Zoog dispatch table
upon entry into a program, we cannot use a vanilla execve to start up
a Zoog child program.  Thus, a bootstrapping program is needed: zload.

However, zload is incomplete at the moment, and doesn't have the
niceties that a bootstrapping program should; in particular, it should
reside somewhere in the far corner of the memory map (as it is, I
couldn't massage the linker script to make something run last I tried)
so that programs don't need complicated linker scripts to dance around
the bootloader.  This is also why the main zkernel does not handle
bootstrapping directly; its memory map is cluttered.

Some other minor modifications here and there as well due to the new
program loading mechanism.
Zload bootstrapping program + dispatch calls working.

The zload bootstrapping program introduced in the previous commit is
now actually working correctly, and runs happily near the very bottom
of memory (0x4000 or so).  After manually loading a specified program
into memory, it sets %ebx to point to a static ZoogDispatchTable_v1
struct (which is supposed to be populated with Zoog call stubs, but
currently is mostly filled with nulls) contained in the zload
program's original address space, then jumps to the newly-loaded
program.

One current downside is that zload still uses the C runtime, which is
a little fat for a bootstrapping program.  Because the program mostly
calls system calls directly (or rather, libc wrappers for them), the
runtime dependency should be somewhat easy to shave off in the future
(in theory, anyway).

The "hello" test has also been modified to showcase the correct
passing of the Zoog dispatch table pointer from zload to the child.
To run this test, run "make && make test && ./zkernel test/hello".
Lines prefixed with "[ZD]" are from the Zoog dispatch stubs.

This commit brings the last of the basic functionality, I think,
required for the Zoog ABI.  The remaining bulk of the work is hooking
the current system up with Firefox and providing the rest of the Zoog
function calls and runtime.
Add NPAPI headers, minor restructuring.