fix forkexectree

hopefully this will migrate less state when stealing.

with tlb shootdowns disabled, radix scales linearly, and crange has
sub-linear scaling.

with VM_RADIX:

  $ time mapbench 1
  12834002141 cycles
  $ time mapbench 2
  12230873801 cycles
  $ time mapbench 16
  12300269260 cycles

with VM_CRANGE:

  $ time mapbench 1
  12969300915 cycles
  $ time mapbench 2
  15277712346 cycles
  $ time mapbench 16
  58582887683 cycles

tom almost runs xv6 well.  xv6 runs into, what looks like, some APIC
issues.

Some results from mapbench on josmp (with DEBUG 0 and VM_RADIX):

When TLB shootdowns are disabled (comment out tlbflush in vmap::remove),
mapbench is perfectly scalable (perhaps a little slow, but it's hard to
tell, because I didn't used to run with readaccess=1):

  $ time mapbench 1
  12403435727 cycles
  $ time mapbench 2
  12439895511 cycles
  $ time mapbench 16
  12200449501 cycles

With TLB shootdowns, things are slightly less scalable, and significantly
slower:

  $ time mapbench 1
  40044138778 cycles
  $ time mapbench 2
  44034668320 cycles
  $ time mapbench 16
  57569203944 cycles

Lazy TLB shootdowns improve performance on 1 core, and have some but
not nearly perfect scalability:

  $ time mapbench 1
  12658404885 cycles
  $ time mapbench 2
  29790759720 cycles
  $ time mapbench 16
  39160961925 cycles

Next step is to understand why TLB shootdowns are so expensive and how
to make them cheaper/scalable.

as detected by mtrace.

mapbench now has only one real cache line of unexpected sharing:
"name": "tlbflush_req+0x0",

use virtual addresses further away from each other in mapbench,
to avoid contending for radix_node cache lines.

This code is inefficient, it doesn't guarantee to find an unmapped
area if one exists, and it only works for crange.