kernel - proc_token removal pass stage 1/2

* Remove proc_token use from all subsystems except kern/kern_proc.c.

* The token had become mostly useless in these subsystems now that process
  locking is more fine-grained.  Do the final wipe of proc_token except for
  allproc/zombproc list use in kern_proc.c
kernel - Remove proc_token, replace proc, pgrp, and session structure backend

* Isolate the remaining exposed topology for proc, pgrp, and session
  into one source file (kern_proc.c).

* Remove allproc, zombproc, pgrp's spinlocks, and start tracking session
  structures so we don't have to indirect through other system structures.

* Replace with arrays-of-lists, 1024 elements, including a 1024 element
  token lock array to protect each list.

      proc_tokens[1024]
      allprocs[1024]
      allpgrps[1024]
      allsessn[1024]

  This removes nearly all the prior proc_token contention and also removes
  process-group processing contention and makes it easier to track tty
  sessions.

* Normal process, Zombie processes, the original linear list, and the
  original has mechanic are now all combined into a single allprocs[]
  table.  The various API functions will filter out zombie vs non-zombie
  based on the type of request.

* Rewrite the PID allocator to take advantage of the hashed array topology.
  An atomic_fetchadd_int() is used on the static base value which will cause
  each cpu to start at a different array entry, thus removing SMP conflicts.

  At the moment we iterate the relatively small number of elements in the
  bucket to find a free pid.

  Since the same proc_tokens[n] lock applies to all three arrays (proc,
  pgrp, and session), we can validate the pid against all three at the
  same time with a single lock.

* Rewrite the procs sysctl to iterate the hash table.  Since there are
  1024 different locks, a 'ps' or similar operation no longer has any
  significant effect on system performance, and 'ps' is VERY fast now
  regardless of the load.

* poudriere bulk build tests on a blade (4 core / 8 thread) shows virtually
  no SMP collisions even under extreme loads.

* poudriere bulk build tests on monster (48-core opteron) show very low
  SMP collision statistics outside of filesystem writes in most situations.
  Pipes (which are already fine-grained) sometimes show significant
  collisions.

  Most importantly, NO collisions on the process fork/exec/exit critical
  path, end-to-end.  Not even in the VM system.