x86: irq handler func pointers

This is more in line with modern OSs (plan 9, linux), where we have some
struct tracking what to do at a given vector, instead of branching on
the trap number.
x86: PICs for everyone!

Turns on the PIC all the time, but masks it.  And cleans up the PIC
initialization a bit, with the goal of removing ENABLE_MPTABLES.
x86: moves the PIC into its own file
x86: moves the PIT into time.{h,c}

It's been cluttering the unrelated APIC files for about five years now.
Adds the UCB-Plan 9 license

With a ref to it in LICENSE, for all the headers that just say LICENSE
and not LICENSE-PLAN9.
Removes shift-G from the escape codes

You can type G now, and have devices like #G.  Crazy!
x86: MP table-detected ISA IRQs can be enabled

This also removes the polling of the serial device, which was a hack for
Ron's AMD board.  If we still need that, even with the IOAPIC, then we
should use a ktask.  And I'll be annoyed.
x86: IDT vector realignment (XCC)

Lays out what each IDT vector is used for, somewhat merging with the
Plan 9 stuff.  These are the vectors that the processor/LAPIC sees, not
the external IRQs.

This also changes the trap syscall vector to 0x40 (64), and the LAPIC
timer vector.

You need to reinstall your kernel headers and rebuild anything that made
trap based syscalls (parlib and all MCPs).  Not sure if you need to
rebuild the toolchain (probably not).
x86: one register_irq() for all types of buses

The 'raw' vectors are just the BusLAPIC type.  I didn't like the nxm way
of relying on BUSUNKNOWN to detect if it was potentially LAPIC.  That
meant you'd always need a bus (like BusPCI) and not just the IRQ for any
external IRQ numbers that were within the LAPIC vector range.

Another way to put it: the LAPIC 'irq' and the global system irq
(devices/acpi) share a different domain, so we need to differentiate on
the bus.
x86: bus_irq_enable()

All IRQs, regardless of acpi/mptable/etc or bus type call the same funcs
to register IRQs.  If we didn't parse MP/ACPI or o/w don't have an
IOAPIC, we'll fall back to using the PIC.
x86: MP table cleanup, multiple IOAPICs

Shuts up the MP table a little, and allows us to handle multiple IOAPICs
without panicing.
x86: can use the IOAPIC even without MP tables

mpparse() usually builds the RDT structs.  If the mptables are missing
or o/w incomplete, we'll need to check with ACPI to fill in the holes.

Checks the ACPI MADT for intovrs or just guesses (which isn't wrong for
ISA) to build an RDT route.

Qemu, at least, has ACPI intovr entries for its PCI NIC.  If we have
hardware with no MP tables and without intovr entries, then we might be
out of luck.  I try guessing, just in case that works.  With MSI, it
should be less of an issue.
x86: IRQ routing and IOAPIC mask/unmasking

The distinction btw enabling, masking, and unmasking is a bit murky.
Right now, you can set up a bus IRQ, and separately mask and unmask it.
But we don't tear down the routes completely yet.
x86: LAPIC vector masking

With another fake bus for IPIs (APIC messages), that can't be masked.
x86: APIC cleanup

Cleanup of debug info, some dead code removal, better header work, etc.

Things work on qemu, though c89 is unhappy about of a bunch of things.
(bigger apics (nlvt > max), multiple botched buses, and a bus_irq_init
with a 0'd TBDF.
Bring in msi support

We're going to have to have it.

Signed-off-by: Ronald G. Minnich <rminnich@google.com>
x86: misc MP/ACPI fixes

Needed more LVTs on some hardware, needed to scan all xioapics (the
array can be sparse), and when we don't have an IOAPIC, we need to treat
IPIs like the LAPIC.

Conflicts:
	kern/arch/x86/ioapic.c
Add comments to msi code; add new pci_clr_bus_master function

The code is actually quite sensible. I'm wondering if we shouldn't
just bypass acpi ...

Signed-off-by: Ronald G. Minnich <rminnich@google.com>
x86: fixes LAPIC unmasking

Was off by 0x320, not that it really had an effect.
x86: LAPIC error handling

We were unmasking the error handler, but didn't have one registered.
We'd take an error, but then fail to send_eoi(), and then never received
further LAPIC IRQs (like the timer).