Fix crash-on-exit in TimerModel

It was possible that signal_end_callback was called after TimerModel has
already been destructed.

Valgrind backtrace:
==3237== Invalid read of size 8
==3237==    at 0x2C2E1EB5: GammaRay::TimerModel::rowFor(QTimer*)
(timermodel.cpp:160)
==3237==    by 0x2C2E226F:
GammaRay::TimerModel::postSignalActivate(QTimer*) (timermodel.cpp:196)
==3237==    by 0x2C2E143F: signal_end_callback(QObject*, int)
(timermodel.cpp:74)
==3237==    by 0x5BC6AE7: QMetaObject::activate(QObject*, QMetaObject
const*, int, void**) (qobject.cpp:3603)
==3237==    by 0x5C282D2: QTimer::timeout() (moc_qtimer.cpp:148)
==3237==    by 0x5BCFCFA: QTimer::timerEvent(QTimerEvent*)
(qtimer.cpp:280)
==3237==    by 0x5BC104F: QObject::event(QEvent*) (qobject.cpp:1156)
==3237==    by 0x68F62EF: QApplicationPrivate::notify_helper(QObject*,
QEvent*) (qapplication.cpp:4562)
==3237==    by 0x68F3662: QApplication::notify(QObject*, QEvent*)
(qapplication.cpp:3944)
==3237==    by 0x80B31F5: KApplication::notify(QObject*, QEvent*)
(kapplication.cpp:311)
==3237==    by 0x5BA7A6B: QCoreApplication::notifyInternal(QObject*,
QEvent*) (qcoreapplication.cpp:946)
==3237==    by 0x5BAB6E4: QCoreApplication::sendEvent(QObject*, QEvent*)
(in /home/krf/devel/build/qt4.8-shared-debug/lib/libQtCore.so.4.8.4)
==3237==  Address 0xf78f620 is 0 bytes inside a block of size 40 free'd
==3237==    at 0x4C2A44B: operator delete(void*) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3237==    by 0x2C2E4C01: GammaRay::TimerModel::~TimerModel()
(timermodel.h:38)
==3237==    by 0x5BC2443: QObjectPrivate::deleteChildren()
(qobject.cpp:1907)
==3237==    by 0x694A49A: QWidget::~QWidget() (qwidget.cpp:1681)
==3237==    by 0x2C2E1004: GammaRay::TimerTop::~TimerTop() (in
/home/krf/devel/build/kdab/GammaRay/lib/plugins/gammaray/gammaray_timertop_plugin.so)
==3237==    by 0x2C2E103F: GammaRay::TimerTop::~TimerTop()
(timertop.h:37)
==3237==    by 0x5BC2443: QObjectPrivate::deleteChildren()
(qobject.cpp:1907)
==3237==    by 0x694A49A: QWidget::~QWidget() (qwidget.cpp:1681)
==3237==    by 0x6E611FD: QFrame::~QFrame() (qframe.cpp:240)
==3237==    by 0x6EDF4EF: QStackedWidget::~QStackedWidget()
(qstackedwidget.cpp:194)
==3237==    by 0x6EDF527: QStackedWidget::~QStackedWidget()
(qstackedwidget.cpp:196)
==3237==    by 0x5BC2443: QObjectPrivate::deleteChildren()
(qobject.cpp:1907)
Split up gammaray_probe

Use two libraries approach:
* Gammaray Core: core library
* Gammaray Probe: probe library (with hooks) linked to core library

Benefits:
* Plugins may link to gammaray_core directly
* We can write unit tests that link against gammaray_core
  Benefit: No hooking mechanisms triggered then
* Clearer separation of what belongs to hooking

It is mostly moving around of code, not too many semantic changes.
There *might* be issues wrt multithreading / missing locks.

New class: SignalSlotsLocationStore for storing and retrieving a
connect() location.
Refactor: Improve coding style in probe.cpp

Use early-returns => less nesting
Proof of concept for moving the GammaRay UI to a separate process.

So far this is a single basic read-only model that is connected to a model
in a separate process using TCP. Far from complete, and lots of temporary
scaffolding.
Add a message structure to the network protocol.

This fixes the issue of the client reading past the stream end if the
server sends too big chunks. So far only the client is ported, server
will follow next.
Use the same network messaging code as on the client side.
Don't reset the model when receiving the initial row/column counts.

Now that we can handle large chunks of data from the server correctly,
this no longer crashes the client.
Allow to reconnect to the server, only accept one connection at a time.
Show loading indicator for requested but not yet received data as well.
Add support for header data.
Unify message types and hide their serialization properly.
Send initial greeting message containing the server version.
Handle the message type inside Message already.

We need access to that on several levels, so this is much more convenient
then passing a value read from the stream alongside the message object.
Change message processing and check for the matching version.
Some initial work on object addressing/registration.

We'll need that to eventually be able to handle more than one model.
More work on object addressing.
We can now address different models on the server.

Still hardcoded on the client side, that's next.
Install the client application as well.
Replace hardcoded object address with dynamic watching for server objects.
Add proper message dispatching on the client side as well.

We can now have to different remote models at the same time.