In SendContinuePacketAndWaitForResponse there is a special bit of

code that looks for a second stop-reply packet in response to an
interrupt (control-c).  This is to handle the case where where a
stop packet is making its way up to lldb right as lldb decides to
interrupt the inferior.  If the inferior is running and we interrupt
it, we'd expect a T11 type response meaning that the inferior halted
because of the interrupt.  But if the interrupt gets a T05 type
response instead, meaning that we stopped execution by hitting a
breakpoint or whatever, then the interrupt was received while the
inferior was already paused and so it is treated as a "?" packet
-- the remote stub will send the stop message a second time.

There's a timeout where we wait to get this second stop reply packet
in SendContinuePacketAndWaitForResponse, currently 1ms.  For a slow
remote target, it may take longer than that to send the second stop
reply packet.  If that happens, then lldb will use that second stop
reply packet as the response for the next packet request it makes 
to the remote stub.  The two will be out of sync by one packet for
the rest of the debug session and it's going to go badly from then on.

I've seen times as slow as 46ms, and given the severity of missing that
second stop reply packet, I'm increasing the timeout to 100ms, or 0.1sec.
<rdar://problem/21990791> 

llvm-svn: 246004