behavior, creating many threads very quickly.  A long debugging session
revealed that the Windows implementation of PyThread_start_new_thread()
was choked with "laziness" errors:

1. It checked MS _beginthread() for a failure return, but when that
   happened it returned heap trash as the function result, instead of
   an id of -1 (the proper error-return value).

2. It didn't consider that the Win32 CreateSemaphore() can fail.

3. When creating a great many threads very quickly, it's quite possible
   that any particular bootstrap call can take virtually any amount of
   time to return.  But the code waited for a maximum of 5 seconds, and
   didn't check to see whether the semaphore it was waiting for got
   signaled.  If it in fact timed out, the function could again return
   heap trash as the function result.  This is actually what confused
   the test program, as the heap trash usually turned out to be 0, and
   then multiple threads all got id 0 simultaneously, confusing the
   hell out of threading.py's _active dict (mapping id to thread
   object).  A variety of baffling behaviors followed from that.

WRT #1 and #2, error returns are checked now, and "thread.error: can't
start new thread" gets raised now if a new thread (or new semaphore)
can't be created.  WRT #3, we now wait for the semaphore without a
timeout.

Also removed useless local vrbls, folded long lines, and changed callobj
to a stack auto (it was going thru malloc/free instead, for no discernible
reason).

Bugfix candidate.

A file-static "threads" dict mapped thread IDs to Windows handles, but
was never referenced, and entries never got removed.  This gets rid of
the YAGNI-dict entirely.
Bugfix candidate.

This closes SF patch #504215.

passed to _beginthread().

This changes Pythread_start_thread() to return the thread ID, or -1
for an error.  (It's technically an incompatible API change, but I
doubt anyone calls it.)

pyport.h:  typedef a new Py_intptr_t type.
    DELICATE ASSUMPTION:  That HAVE_UINTPTR_T implies intptr_t is
    available as well as uintptr_t.  If that turns out not to be
    true, things must get uglier (C99 wants both, so I think it's
    an assumption we're *likely* to get away with).
thread_nt.h, PyThread_start_new_thread:  MS _beginthread is documented
    as returning unsigned long; no idea why uintptr_t was being used.
Others:  Always use Py_[u]intptr_t, never [u]intptr_t directly.

This should match the situation in the 1.6b1 tree.

   with uintptr_t (fix MSVC 5.0 build)

declarations yet, those come later.