support qfThreadInfo and qsThreadInfo

[tromey]

These commands fetch the list of threads. They are unusual in that they form a sequence: first a qfThreadInfo, then a series of qsThreadInfo until the list of threads is exhausted. So, this will require a sort of nested packet reader.

[luser]

Yeah, this seems like kind of a pain in the ass. I guess we can have like Handler::get_threads that returns either an &[ThreadID] or Vec<ThreadID> and the protocol parser can deal with this nonsense. Presumably this is only an issue if the serialized list of threads won't fit into a single packet?

[tromey]

I think it is always needed, because qsThreadInfo is the way to terminate the list; however, multiple qfThreadInfos are only required if there is a packet overflow. I totally agree that Handler should not know about this, only the protocol code.

[tromey]

This might actually be simpler on the multi-threaded branch, because the qfThreadInfo handler can simply listen for additional commands, and return after seeing qsThreadInfo.