I think the semantics used to be that the iterator would always start
at the first non-null element, which I broke when I switched to the
iterative implementation.  This fixes that and introduces a method
that will be useful once iterators can point to null elements.

This puts the trivial part of the radix_iterator constructor used by
end() in the class definition, so the compiler can see the full
definition of end().  This should let it inline it and, hopefully,
constant-eliminate it so it doesn't get called repeatedly.

In standard collection types, begin and end are methods of the
collection.  The global begin and end are defined in <iterator> and
simply call these methods.

Previously, the radix iterator unconditionally found the next non-null
leaf node, even if it fell outside of the range the iterator was
derived from.  This was obviously an efficiency issue, but it also
introduced unnecessary sharing because of the reads outside of the
iterator's range.  Now it takes an explicit upper bound and will stop
resolving elements when it reaches that bound.  The end() iterator is
now naturally represented in terms of this bound, rather than in terms
of a special-case key.

For asharing vm, this eliminates all violations of the commutativity
rule.

Since I couldn't figure out how to nicely work this bound into the
existing recursive traversal implementation, I reworked it to be
iterative and, I think, made it much simpler in the process.  This
does make one notable semantic change: previously the radix iterator
cached the element it pointed to, so an update to that element would
not affect the value returned by the iterator.  It no longer caches
it, which makes it behave more like a regular collection iterator.

Unfortunately the timer fails raise an NMI when ben "locks up" during
boot.  Maybe this happens because I'm "locking up" the x2apic somehow
and the watchdog NMI is routed through the x2apic..

I hadn't realized before that mscan tracks "block" labels and "type"
labels separately and prefers type labels over block labels.  So, in
fact, kalloc's should always be labeled (using block labels) and
suballocations from these blocks should also be labeled (using type
labels).

Previously, radix_node's constructor would zero all of the pointers.
Now we use zalloc.  This fixes physical sharing between the mmap that
first allocates a radix node and every other operation that does
anything in that node (I argue this is not just sweeping this problem
under the rug: mmap obviously does not commute with address space
creation, which could theoretically pre-populate the radix tree.
Since that would consume too many resources, we do it lazily.  The
resulting physical sharing is exactly the same, it just happens at a
different time.)

This was originally to make radix_node rcu_freed, but that
didn't happen.  9x4 makes each radix_node one page and thus
easier to allocate.

zalloc uses work queues.  Technically, we're okay as long as we don't
*use* the zallocator until wq is initialed, but that seems fragile.

percpu acts like a T* const, so a const percpu should (also) be like a
T* const, *not* like a const T*, which is what the code previously did
(remember, C types are inside-out!  except when they aren't).  This,
for example, makes it sane to pass a const percpu reference.

This also makes percpu non-copyable and non-assignable and makes stuff
private.

Previously, we always used the name of CPU 0's kmem for a slab (owing
to the same type of pointer decay problem fixed by the last commit).
This is why all mtrace labels are called things like "0kstack" instead
of having the right CPU number.

Previously, ksfree passed the whole CPU array for a slab to
kfree_pool, which expected a pointer to the specific kmem to free to.
Since the array decayed to a pointer, this compiled and worked, but
would always free to CPU 0's slab.

RCU-freeing the radix_nodes was punted for now, so we shouldn't need
this.

We use it for the AP boot code and stack and could free it after that,
but it's easier not to.

Simplifies the range locking code. Also we don't need that silly struct.

Simplifies things. radix_node is not RCU-freed and remains a power of
two. update_range always succeeds and doesn't need to return how far it
got.

Start at the appropriate index and stop early enough.