Multiboot memory detection fixes

A few things:
- Multiboot's regions don't cover all of physical memory; it has holes.  We now
  init the pages[] array (for x86) to mark all pages as busy, and explicitly
  mark the free pages.
- The previous version of this worked a little, since the unmarked, non-free
  pages weren't on any free page lists.  However, the contiguous memory
  allocator (which is really lousy btw) looks directly at refcnts, bypassing
  the lists.
- One problem is that there is a big chunk of unusable memory around 0xfec00000
  (IOAPIC and friends).  This was working okay with multiboot's memory
  mappings, but not with qemu's "here's a lot of memory" approach.  In lieu of
  doing full-fledged memory detection/probing, I'm just ignoring physical
  memory from [0xc0000000, 0xffffffff].  This only applies to qemu, when
  launched with the -kernel flag.
- 32 bit had some other issues when giving out memory near the 4GB mark, as
  well as having other issues with 64 bit addresses (note some of the changes
  from %p to 0x%016llx).
- The bug with giving out pages that were mapped to IO/BIOS/x86 magic regions
  in high memory showed up as clobbered bookkeeping in small slab pages in
  kmem_cache_grow() (stored at the end of the pages improperly allocated).
  Good times!
WIP