Add FPU state to signal handler context

[Chris Turner]

This issue was brought to light with respect to some recent
interactions with sysmouse & xf86-input-mouse > v1.2.1
(see #871, users@ list ~2007-11-08) as well as
http://mail-index.netbsd.org/pkgsrc-users/2007/08/06/0008.html

Matt States:

Should we start saving and restoring the FP context?  The ucontext
structure does have enough space reserved for it.  During the LWP
work we expanded the FP save space to 512 bytes.
Basically code would have to be added to sendsig() and sigreturn().

    sendsig():
	* Check if the FP is used by the process.  If not, nothing
          to do.
	* If it is, but it isn't active, copy the saved state to the
          ucontext
	* If it is, and it is currently active, save the current state
          to the ucontext.
	* Set flags in ucontext appropriately to indicate that the FP
          state has been saved.
    sigreturn():
	* If ucontext has flagged that it holds FP state, restore the FP
          tate from the ucontext.
Nuno Antunes pointed out a regression test in OpenBSD's tree:

http://www.openbsd.org/cgi-bin/cvsweb/src/regress/sys/kern/signal/fpsig/

I took a crack at implementing this but couldn't figgure enough about 
how the stack & registers are mapped out to implement according to above..

some notes:

/usr/src/sys/platform/pc32/i386/machdep.c:
   - sendsig:
   - sys_sigreturn:
. /sys/sys/ucontext.h:
      typedef struct __ucontext {
. ..
                     mcontext_t      uc_mcontext;
. ..
where:

. /sys/cpu/i386/include/ucontext.h:
   has the various register's +=
            int     mc_fpregs[128];         /* full fp state */
            int     __spare__[16];
   which I believe matt was referring to above..
   along with:
    #define _MC_FPOWNED_NONE        0x20000 /* FP state not used */
    #define _MC_FPOWNED_FPU         0x20001 /* FP state came from FPU */
    #define _MC_FPOWNED_PCB         0x20002 /* FP state came from PCB */
which as I recall are used in the function calls above.

perhaps I'll take another crack at it soon, in the meantime,
perhaps this might help someone else.
As a side note, posix doesn't seem to mention this definitively one way
or another - due to the possiblility of SIGFPE occurring within a 
handler I'm not sure that it's the wisest thing to do in the first 
place.. It might be worth considering if the potential dropped signals 
resulting from SIGFPE in an implementation of this fix.