Ktasks are run with interrupts enabled

In general, I think most ktasks should have IRQs enabled.  If not,
disable them (temporarily) when needed.
Fixes random reads

This is the old plan9 style, with two 'independent' processes working at
the same time, and not using apipes.

But it's way too slow:

/ $ trandom 16
Read 16 bytes of random in 822003 microseconds
dc6bd80d 9b541b97 a063d7ab 27d7bbea
/ $
/ $ trandom 100
Read 100 bytes of random in 5192485 microseconds
fe50907c 5c5c7473 5d40b3fe 307fbf4c

I think it's slow since genrandom doesn't yield to processes.  When
we're done with our 16 bytes, we pause a bit before returning to
userspace.
Uses apipes and no alarms for random numbers

This is better than my old 9ns change to devrandom, in which I didn't
fully understand how the original random code worked.

It's also faster than the our inferno version (due mostly to not taking
13 ms for 2 bits of randomness), and much simpler, due to the apipes.

It also passes the extremely rigorous test for randomness, established
in the old 9ns commit 7f63102c: I can't see a pattern in a bunch of 16
byte random reads:

b42b0a02 1f0740d0 9064d97d ae2a0a02
dd37e3b8 d6f57d77 fd2f8b62 6759d5f5
3d4fd39d dd6d5bd6 e779d775 354dd39d
f39f6759 5f5735cd dff7fd7f f39fe7f9
244934cd 89a22892 59d5759d ce739765
384e9339 b78b2288 8ee37edf e0b8ae3a
f7ef3b0e 82a07ade d7759d09 d39de779
ecfb3f4f 8b2208b0 d9ddf7bd b82e9264
320c03e0 3283a028 751d21c8 9f6759d5
3d23c8f2 8ae2def7 ea3a8e28 ae1a86a1
8a62e6b9 d7759d29 1231cc73 a0282248
0a022008 280a8228 77771d87 4ad27ddf
Adds bind to userspace
Fix VFS hack bug

Dup wasn't returning the lowest available FD, since the VFS wasn't
telling 9ns about closing its FDs.
Pipe cleanup (XCC)

Using the 9ns pipes exclusively, so no need for SYS_npipe.

Note the omode change.  That goes back to 424240126c, and it'll be a
concern for all new devices.

Reinstall your kernel headers (or just don't use SYS_npipe).
Fix a bunch of %lud and %lux

Plan9 has a bunch of trailing ds and xs that our printks don't support.
Fixes OREAD / omode checks

The idea behind 424240126 was alright, but when we masked with OREAD, we
were just zeroing everything out.  Did I mention having OREAD/O_RDONLY
the value zero is a bad idea?

Now, we can use the more clear helper IS_RDONLY().  Which we can change
later if so desired.