Fix spurious IRQ check
x86: sends the EOI later in the IRQ path

I've gone back and forth on this.  Check out 1b50da7e for reference.

Right now, we're taking more spurious IRQs, probably due to sending EOI
early.  It's not necessary for ipi_is_pending() to send early either,
and I don't see other OSs doing it.
x86: locking when messing with the PIC

This is ultra-paranoia.  In general, we only mess with the PIC from
core 0.  That's the only core we route PIC IRQs to.  But there's a
chance we have an MCP that triggers something like a mask or unmask of
the PIC, which could happen concurrently with an IRQ.  I don't know if
we have anything that can do that yet, but better safe than sorry.

As far as the extra perf overheads go, ideally we wouldn't even be using
the PIC, but we'd have the same set of issues with the IOAPIC, and will
need locking in those cases too.
Fixes minor printing bug

Also, feel free to comment out the namec() nexterror(), if you want the
regular behavior.
Queue limits use data length

Queues were using the allocated length of the queue's blocks when
judging the size of the queue.  Now they use the data length.  The
data length is the useful bytes in the queue.  The allocated length
includes extra padding and whatnot.  For instance, every block from the
igbe driver has an allocated size of 2KB, but most packets are much
smaller than this.

Prior to this change, the queue limit-check limits the amount of memory
consumed by the queue.  Now, the limit-check limits the amount of data
in the queue.  Since the network code / queue consumer is the one that
sets the limits, this makes more sense.  For instance, if network stack
code (like TCP) establishes queue limits (64K, 192K, etc), then you'd
think those limits should have something to do with actual network data,
not with whatever block allocation the driver happens to use.
x86: helper for PCI bus mastering

Probably every PCI device that needs to DMA will need to set this.
PCI cleanup

Includes helper functions for reading/writing 16/8 bit registers in the config
space and the ensuing cleanup.

Also includes better detection of multifunction devices; we only scan
for them if we know we have a multifunction, instead of scanning all the
time.  We also were missing out on the header type frequently, since we
didn't mask 0x7c.
Dynamic virtual memory mapping helpers

We'll see, but most users probably just want the mapping to happen, and
don't care about splitting up the getting the segment and doing the
mapping.
PADDR helpers for lower and upper 32 bits

We usually need to tell devices 64 bit PADDRs in two separate 32 bit
chunks.  Also, I added some catches for the RTL driver.  Without this
check, we could have the NIC writing on the wrong pages (when the true
PADDR > 4 GB).
Fixes minor casting bug
igbe/e1000 driver ported

There's some OS-independent bug fixes in there too, check the comments
at the top of the file for details.

Also, we don't do IRQ reassignment yet, so we don't properly support
systems with multiple NICs using the same IRQ.
Attempts to fix netifgen

If you bound #l0 to /net, then tried to ls /9/net/ether0 (without any
conversations in there), then we'd lock up.

The root of the problem goes back to ecff8a, when I tried fixing our
inability to stat /9/net/ether0/1/ifstats.  In the process, I broke
stating /9/net/ether0/{stats,ifstats}, which you'd only notice if you
didn't have any convs in ether0.

The root issue is that netif code can't tell the difference between a
QID with a netid of 0 and one with no netid at all.  I think I fixed it.
I left in my comments for the next time we need to debug this.
Fixes build errors with ndblib

Some files weren't including fcall, and setnetmtpt() wasn't implemented
(caused link errors with tests/cs.c).