Get msgtst working on bochs

There was a bug in the pic implementation
fixed parcing of ACPI MADT table to properly tell us the number of cores to work on vmware as well
bunch more cleanup, now works multicore on vmware
notes for running on fusion
Boot using KVM on kd

There were a couple bugs:

1. An optimization of the loading of the gdt using KD's compiler. This
has been fixed with the use of volatiles

2. The init IPI was not level asserted and not being responded to.
Merge pull request #17 from dschatzberg/forSESA

x86 baremetal update
Remove ACPIA

The ACPICA code was ripped out and replaced by our own implementation
where we find the table. I discovered that we indeed need to map more
memory on kd because of the existence of a table in higher memory.
Fix numerous baremetal bugs

All tests seem to be working now. There were several subtle bugs that
required some modifications.

- The event location is assumed to be linear for a lot of our code but
  the apic id is not linear, so some mapping had to be done.

- There was an issue where we forgot to zero out the IDT (It was
  switched from bss to allocated recently). On hardware this caused a
  general protection fault that was quite hard to track down

The outstanding concern is with the ioapic which isn't being
initialized. It should initialize to reasonable defaults (no IRQ
routing). The issue is that this IO APIC has a different version than
the one I setup with, so I am apprehensive about just initializing it
the same way as the other version.
Re-enable IO/APIC

I had disabled the IO/APIC initialization, but after a bit of testing
decided it seems best with the initialization on.
Merge pull request #18 from dschatzberg/forSESA

Kd-baremetal fix
first pass at machine independant memory allocation for boot
have to set the bitvector atomically
fixed bindtst to exit on a failure
changed event.c to call lrt_mem_alloc, rather than malloc
fixed spacing
moved generic spin lock implementation out of MsgMgrPrim
fixes to get mem changes compiling bare metal
fixed invalidate of remote local translation entries

On hardware the local translation tables are aliased, using both
memory mapped entries when accessed locally, and identity mapped
addresses for remote access.  When invalidating the remote entry
we were using the wrong addresses to re-initialize them.
Merge pull request #19 from okrieg/development

Fix up lrt_mem_alloc on ULNX
Merge commit 'SESA/development' into ppc-bm