When we do synchronous process execution in lldb, the call that restarted the target will generally have acquired first the TargetAPI lock, and then the Process RunLock. If in the process of handling that continue we need to run Python code in the private-state-thread (e.g. for an OS plugin or scripted ThreadPlan) if that Python code calls another API that takes the Target API mutex, we will deadlock. However, the private state thread is always doing work on behalf of whatever thread initiated the continue. So the private state thread should always formally be allowed to pass the lock check.
We already handled this in the case of the Process RunLock by passing out separate locks depending on whether you were running code in the private state thread or anywhere else. This patch just does the same thing for the Target API mutex.
I also added a test using a scripted ThreadPlan that calls various SBFrame and SBValue API's which take the API lock in the should_stop method of the plan (which is always run on the private state thread).