0 is not a system call (thanks to Peter Froehlich)

Previously, these were inconsistent: they used their struct proc
argument for bounds checking, but always copied the argument from the
current address space (and hence the current process).  Drop the
struct proc argument and always use the current proc.

Suggested by Carmi Merimovich.

Invoke initlog from forkret on first user process

usertest for big write()s
push begin_trans/commit_trans down into syscalls

Very important to give qemu memory through PHYSTOP :(

Passes usertests and stressfs
Seems to recover correctly in a number of simple cases

Variable declarations at top of function,
separate from initialization.

Use == 0 instead of ! for checking pointers.

Consistent spacing around {, *, casts.

Declare 0-parameter functions as (void) not ().

Integer valued functions return -1 on failure, 0 on success.

Remove the stack guard page.  Processes are now contiguous from 0 to proc->sz, which means our syscall argument validation is correct.  Add a pointer validation test and remove the stack test, which tested for the guard page.

increase PHYSTOP

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

nits in comments

Various cleanup:

 - Got rid of dummy proc[0].  Now proc[0] is init.
 - Added initcode.S to exec /init, so that /init is
   just a regular binary.
 - Moved exec out of sysfile to exec.c
 - Moved code dealing with fs guts (like struct inode)
   from sysfile.c to fs.c.  Code dealing with system call
   arguments stays in sysfile.c
 - Refactored directory routines in fs.c; should be simpler.
 - Changed iget to return *unlocked* inode structure.
   This solves the lookup-then-use race in namei
   without introducing deadlocks.
   It also enabled getting rid of the dummy proc[0].

lots of cleanup

idecref cwd in exit

delete unused functions
a few comments