Better handling of resuming instrument sessions by SCPIDevice

[chille]

I have identified a few problems in the SCPIDevice constructor:

1. If there is more than three lines of crap in the RX buffer before the *IDN? request is sent, thenthe identify will fail. I'm not sure if this is a theoretical problem, or something that can happen.

2. If there is one or two lines of crap, then *IDN? will succeed, but there will still be crap in the buffer afterwards. This is supposed to be cleaned up by calling m_transport->FlushRXBuffer();. However the C++ code is so quick that the cleanup will most likely be done before the other data is even received from the instrument. (This is the problem I'm encountering right now.)

3. There is no way to temporarily activate the rate limiting API or use the dynamic rate limiting to solve problem 2.

I would suggest the following:

1. Split the identify code to a function named SCPIDevice::RequestIdentity(), or similar. And then call that function from the constructor. This gives a little more flexibility on how to initialize stuff without calling the SCPIDevice constructor.

2. Call m_transport->FlushRXBuffer(); before RequestIdentity(). Maybe this should be configurable via a parameter bool clearBuffersBeforeStart = true that can be disabled. I have no idea if this might break other things. But I would assume not. If there is some driver that are able to resume a connection and get the state from the instrument, then it makes no sense to automatically ask for *IDN?.