i386_set_gdt

I'm again able to build oskit kernels that work and use serial gdb on them,
so I have been able to get started on a little oskit-mach hacking and
should be ramping up from now.

Reversing the previous commitment, I have nixed the %gs:0 magic support.
Instead, I've replaced it with new interfaces in mach_i386.defs that work
exactly like linux-2.5's set_thread_area/get_thread_area system calls.
That is, there is a new RPC i386_set_gdt that you call similarly to
i386_set_ldt.  But instead of giving you a per-thread LDT to switch to, it
leaves you using the kernel LDT and copies in these special GDT slots on
context switch.  According to the Linux people this is very efficient.  It
gives (almost) all the flexibility of using LDT, but is faster for when you
really only need a couple of extra slots.  In fact, we only really need one
at the moment, this implementation as it is gives you two, and Linux gives
you three.  

I took the opportunity to rearrange the GDT entries the kernel uses,
informed by the Linux layout (but not the same).  This is really invisible
to everything, except oskit code that thinks it knows the base_gdt segments
like i16 stuff, and we already don't use any.  The new layout probably
performs better, not that we could measure the difference.  

I contemplated moving the kernel LDT entries into the GDT
(i.e. USER_CS/USER_DS), but decided not to for now.  I guess but don't
really know that GDT slots are marginally more efficient that LDT slots and
hence preferable by default.  This would be technically a user-visible
change, but not a change in the supported semantics--just the segment
selector values seen in user threads would change, but already users aren't
supposed to presume what those are.  Linux uses GDT slots for the user
segments.  The reason I can think of that Mach didn't is that it avoids
having the standard user segments visible to a thread using a private LDT,
so e.g. some kind of emulation task could be set up that wouldn't be able
to escape the emulation by using the normal linear user-mode segments.  I
don't think we care about that now.  Anyway, we still need an LDT for the
system call gate, and that couldn't move out of the LDT without changing
the user-mode ABI for syscalls, so I just left the whole kernel LDT alone.

I haven't tested the new interfaces at all, but it couldn't really be wrong
except for a typo I can't see.  It's very simple.  I have tested that the
kernel with the new GDT layout boots and works to a first approximation.