provide python interpreter for mussa qui via a seperate thread

provide python interpreter for mussa qui via a seperate thread
helps ticket:201
Since both the python read-eval-print loop and Qt have their own
event loops one can't easily have a single threaded application
provide GUI code while still having an interpreter sitting around.
Additionally due to the limitations of OS X and Windows, the main
thread needs to be the GUI thread, so I needed to start the python
interpreter in a seperate thread.

I implemented several helper classes in qui/threading to help manage
creating threads. Currently it just provides a singleton interpreter
thread. The interpreter when started in its subthread will try to
initialize ipython, and if that fails will try InteractiveConsole
(I suppose I should've caught that failing, and then finally fell back
to the fgets read-eval-looop).

The way access to the GUI layer is handled is via a signal/slot thread
specific proxy class which holds a mussa analysis object and notifies
the copy in the main thread via a signal to create a new window using
the provided mussa object.

Access to some parts of the mussa object are thread safe, because I was
so enthusiastic about marking functions as const. All the other parts
are, shall we say, "up for grabs".

The other issue is I really need to improve the CMake scripts to be
a bit more robust about deteriming if python should be linked in.
(And one of my tests breaks because of this patch).

But since it works on OS X I want to know what it'll do on linux.
I'm pretty sure since a windows GUI app doesn't have a console that
it won't work on windows. (To say nothing of the command line
argument parser crashing under windows).