Simplify allocuvm/deallocuvm to operate in a contiguous memory model.  This makes their interface match up better with proc->sz and also simplifies the callers (it even gets the main body of exec on one page).

Rearrange proc.h and proc.c to get our action-packed spreads back (mostly).  They also make sense in this order, so it's not just for page layout.

do not keep sorted contiguous free list

put an invalid page below the stack
have fork() handle invalid pages

fix corner cases with alignment when mapping kernel ELF file

Includes code for TLB shootdown (which actually seems unnecessary for xv6)

this time do it ourselves instead of piggybacking on TLS.
add -fno-pic to Makefile; pic code breaks our fake TLS.

still not quite but a lot better.

 * rename c/cp to cpu/proc
 * rename cpu.context to cpu.scheduler
 * fix some comments
 * formatting for printout

pdf has very good page breaks now.
would be a good copy for fall 2009.

group locks into structs they protect.
few naming nits.

Some proc cleanup, moving some of copyproc into allocproc.

Also, an experiment: use "thread-local" storage for c and cp
instead of the #define macro for curproc[cpu()].

timer-preempted kernel thread resumes execution in trap() after yield().
otherwise the kernel could get an arbitrary number of nested timer intrs.

Final word on the locking fiasco?

Change pushcli / popcli so that they can never turn on
interrupts unexpectedly.  That is, if interrupts are on,
then pushcli(); popcli(); turns them off and back on, but
if they are off to begin with, then pushcli(); popcli(); is
a no-op.

I think our fundamental mistake was having a primitive
(release and then popcli nee spllo) that could turn
interrupts on at unexpected moments instead of being
explicit about when we want to start allowing interrupts.

With the new semantics, all the manual fiddling of ncli
to force interrupts off in certain sections goes away.
In return, we must explicitly mark the places where
we want to enable interrupts unconditionally, by calling sti().
There is only one: inside the scheduler loop.

test: store curproc at top of stack

I don't actually think this is worthwhile, but I figured
I would check it in before reverting it, so that it can
be in the revision history.

Pros:
  * curproc doesn't need to turn on/off interrupts
  * scheduler doesn't have to edit curproc anymore

Cons:
  * it's ugly
  * all the stack computation is more complicated.
  * it doesn't actually simplify anything but curproc,
    and even curproc is harder to follow.