Simulation backend

[hacst]

This issue is more of a collection and ongoing discussion about the design of the backend. Separate issues should be created for the different concrete implementation aspects before tackling them.

@chris- I would propose implementing a prototype for a simulation backend matching the following criteria as I remember them from our discussion:

• [x] Cleanly separated from the GUI
• [x] Simulation driven by a time indexed priority queue of line events
• [x] Gives GUI enough information to render pulses moving on the wire
• [ ] Allows storing and loading of simulation models
• [x] Allows the GUI to store data blobs into the model that are opaque for the backend. This would for example be used for x,y positions of element instances.
• [x] GUID based identity model for circuit components so clean interaction between user created components can be possible later on
• [x] Must only use basic python OO constructs to simplify later optimization and porting of the backend which is likely required for large scale simulations.
• [x] Allow GUI to turn circuit on or off. Nice to have: Allow GUI to edit the circuit while running simulations.
• [ ] Nice to have: Separate backend into separate python process.
• ...

Open for discussion & ideas down the road:

• Should the user be able to store all logic states of the circuit. This is useful for complex circuits with a lot of storage capabilities (shift registers, flip flops, rams).
• After some performance analysis, we might consider using a different language for modeling update functions for logic elements like e.g. LUA.

[hacst]

Missing now are store and load of simulations - groundwork for this is in the serialization/deserialization function - as well as the strict process separation. Interface and datastructure wise we pretty much should be able to perform the split. Remaining is figuring out how to perform the startup and pass the queues to the main-application without making the classes depend on the multiprocessing module.

I think completing the "nice to have" separation is worth it as it will automatically prevent us from accidentally coupling frontend and backend in ways we later regret.