Replace the LWKT token code's passive management of token ownership with

Replace the LWKT token code's passive management of token ownership with
active management based on Jeff's spin locks (which themselves are an
adaptation of Sun spinlocks, I tihnk).

LWKT tokens still have the same behavior.  That is, even though tokens now
use a spinlock internally, they are still active only while the thread
is running (or preempted).  When a thread non-preemptively switches away
all held tokens are released as before and when a thread
switches back in all held tokens are reacquired.

Use spinlocks instead of tokens to manage access to LWKT RW lock structures.
Use spinlocks instead of tokens to manage LWKT wait lists.

Tokens are designed to fill a niche between spinlocks and lockmgr locks.
Spinlocks are only to be used for short bits of low level code.  Tokens
are designed to be used when broad serialization is desired but when the
caller may be making calls to procedures which might block.  Lockmgr locks
are designed to be used when strict serialization is desired even across
blocking conditions.

It should be noted that token overhead is only slightly greater than
core spinlock overhead.  The only real difference is due to the extra
structural management required to record the token in the thread structure
so it can be released and reacquired.  The overhead of saving and restoring
tokens in a thread switch is very rarely exercised (i.e. only when the
underlying code actually blocks while holding a token).

This patch reduces buildworld -j 8 times by about 5 seconds (1400->1395
seconds on my test box), about 0.3%, but is expected to have a more
pronounced effect as further MP work is accomplished.