Rewrote test app to use std::thread instead of pthreads because Windows doesn't have pthreads. This involved changing it from a C application to a C++ application.
Added missing code in HandleCreateThreadEvent and HandleExitThreadEvent to actually track the threads.
Modified ExceptionRecord to keep track of the ID of the thread that caused the exception. This resolves the discrepancy between the PC and the breakpoint address in the exception record, which allows the code to find the breakpoint that was hit and thus recognizes that the thread needs stop info.
Changed ProcessWindowsData::m_exited_threads to be just a set of thread IDs, since there are no HostThread objects to map to for threads that are gone.
Fixed some of the logging in ProcessWindows (like the order of some parameters and more consistent use of hexadecimal for thread IDs).
Fixed crash in ProcessWindows::OnExitThread when terminating a multi-threaded inferior.
Plumbed through the exit code for a thread, but not actually using it yet.
You can probably make this a DWORD. We need to use the lldb types whenever it's somethign that's exposed from the plugin through an API, or when it's in some code that otherwise needs to have a stable interface among different platforms. But for internal types we should be using the native OS types. lldb::tid_t and pid_t are both 64 bits I think, and process / thread ids are 32 bits on windows, so there's ugly casting going on at every call site if we use the lldb public types internally.
(Also feel free to fix up any instances of this where I didn't follow my own rule)