Previously we assumed in many places that all pages between a VMA's
vma_start and vma_end belonged to that VMA.  For radix, the radix tree
is now the source of truth about which pages a VMA maps.  This will
let us replace subranges of a VMA without having to split the VMA into
two ranges (which would violate the commutativity rule; e.g. for
disjoint unmaps within the same VMA).

These methods are to support changes in the VM system.  key() and
span() let you interrogate the current position of the iterator.
next_change() and the copy/move constructors make it easy to work with
spans of equal elements.

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.