Add sketch for possible backend architecture.

This commit adds the basics of an event based
simulation backend. The core of the simulation
is a time based priority queue of events. An
event is something that is scheduled to occur
at a certain time triggering the scheduling of
zero or more subsequent events.

On top of this core there is a base-class Element
from which all simulation elements are derived.
This abstract class defines the interface elements
have to implement to be able to interact inside of
the simulation. Between elements events take the form
of timed signal transitions called Edge. These are
emitted from one of the connected outputs of an element
to one of the inputs of another element.

Inputs and outputs are identified by indices and
only meaningful in connection with their corresponding
element.

Interconnects are meant to map closely to the LineTrees
we use in the GUI as it would probably be pretty painful
to manage the meta-data for the GUI later on if we split
them up into basic point to point connections.

This commit also adds the simple element which is used
for the implementation of some basic logic elements
(and, or, xor, nor, nand). It allows defining a new
element in terms of its input state to output state
mapping function. There's likely some performance to
be gained from optimizing this.

For now the core is tuned to execute events as fast as
it can with no regards for any relation of simulation
time to wall-clock-time. This can be easily be changed
later to accommodate direct user interaction.

The current design does not yet have any provisions for
exposing state changes and meta-data to the UI. If we
go with this design we will likely want to have each element
carry meta-data for the UI and add forwarding of executed
events to the UI. We might need some virtual event generation
to simplify the job of the UI when it comes to seing output
states of elements.
Introduce total event ordering to prevent event racing issues.

Without total event ordering we cannot properly
handle things occurring at the same time at the moment.

We can probably solve this another way but with the current
architecture if we have two edges on different inputs on the
same element at the same time we can't apply them without
scheduling an independent output event for each edge. This
isn't a problem as long as our output events stay ordered
correctly. If they don't we might end up in an invalid state.
Add very basic unit test coverage of AND and OR Gates.
Add coverage for backend.Interconnect
Minor fixups.

- Start clock at -1 so we can schedule to time 0.
- Extended call-track to be able to track other members
  than "slot"
Extend and unify element interface.

For the elements to properly interact they have to
have a unified interface. The simple_element specific
attach is replaced by a generic connect method on the
element (as well as a disconnect method).

Also introduced a reset function which is meant to be
used on circuit initialization to propagate the right
states throughout the circuit. For that it basically
creates an edge with the current output state on each
output of each element.
Introduce compound elements.

The idea of compounds is to allow grouping of multiple
elements inside of one element. To allow this the
compound element acts like a normal element with inputs
and outputs to the outside but has input and output
indirection capabilities that can be used to wire up
the internal elements to those virtual input and output
posts.

Edge transitions are - currently - directly forwarded
to the corresponding connected internal element. Edges
on pins not internally connected are ignored.
Add tests for core and compounds.