New dtrace release for 32b/64b syscalls

Put out an updated dtrace to fix the 32bit syscalls on a 64bit
kernel, via the module part of a probe name. We set this to "x32" or
"x64". By default, you would wildcard this field:

$ dtrace -n syscall::open:

but now you can elect to monitor, e.g. just 32-bit syscalls:

$ dtrace -n syscall:x32::

Took me a while to figure out how to determine if we are on a 32-bit
syscall or 64-bit one. Technically, its not the syscall which is 32 or
64 bit, but the process (actually, current thread). I had a silly in the
code so that no 32-bit processes were being trapped.

In examining the kernel code, theres various things that could be done
by a process which might confuse the kernel. Most of the kernel makes
no distinction between a 32-bit app and a 64-bit one. Things
like the ELF magic part of the initial a.out file can be overwritten,
without transforming a process from one more to another. The later kernels
cache a bit to indicate which mode its in, but its rarely consulted.

There is a personality field in the thread structure, so it would
be definitely interesting to change this to try and flip from
32 to 64 bit modes.

Post created by CRiSP v10.0.3a-b5937