Run adapter in separate thread

[MichaelWedel]

For #195 it will be necessary to run adapters in separate threads, because of some problems we've been seeing in different scenarios where the things done in one cycle are very long for some reason. This is particularly pronounced with pcaspy.

Before implementing multiple adapters, where this multi-threading will most likely be a strict requirement, we should figure out how this is done for one adapter.

[MikeHart85]

Been thinking a bit more about how this might work / be implemented.

For Stream and Modbus adapters, it would be relatively easy to make this work because they are packet based... we could just do this:

• Separate the Adapter and Interface layers more
• Have Adapters run in worker threads
• Have Interfaces run as part of the main simulation cycles
• Use thread-safe EventQueue and ActionQueue to pass commands between them
• Adapter constantly pushes to EventQueue as commands are received, consumes ActionQueue to send responses
• Interface does the opposite, but only when it is its turn during a cycle

EPICS could in principle work similarly, but the trouble with it is that it is more transaction based. Specifically in PropertyExposingDriver.write(pv, value), we cannot just queue up an Event to write value to pv later... because we need an immediate response for the return value. True if the write succeeded, and False if the write failed for whatever reason (pv doesn't exist, value is invalid, ...). If we fake it by always returning True, this would change caput behaviour in a bad way.

Not sure how to solve this. Especially since the EPICS adapter is one of the main reasons for wanting to thread the adapters in the first place. Perhaps there is a different way that would be better than threading after all.