Optimize the ObjectListModel.

- Do not use a read/write locker, user a simple QMutex. We only read
from the main thread, where we also write. We never have multiple
readers thus the overhead of a reader/write lock is not justified.

- sort list of objects, use binary searches which greatly improves
the performance of removing objects, since it's no longer O(N)
but O(log(N)).

- to keep a stable sort order, don't operate directly on m_objects,
rather keep the invalid objects in a separate set. This allows us
also to return rowCount without any locking. We can also scope
our locks much better in the other functions.

The down side is a bit more complicated code, but that is mostly
due to lots of assertions being added.

I used KDevelop as testcase, as it's the most heavily multithreaded
Qt app I know and it works.
Remove errorneous assertion.
Add a benchmark for Util::iconForObject.

This showed up as a hotspot while profiling GammaRay. The benchmark
gives the following number on my machine in RelWithDebInfo:

0.054 msecs per iteration (total: 56, iterations: 1024)
Optimize Util::iconForObject by parsing the resource file once.

The benchmark shows that this greatly improves the performance:

0.0012 msecs per iteration (total: 84, iterations: 65536)
Add a benchmark for the connection model's connectionRemoved.

On my machine with RelWithDebInfo the benchmark gives:

65.2 msecs per iteration (total: 652, iterations: 10)
Optimize ConnectionModel::connectionRemoved.

By calling the function directly if we are already in the main thread,
we can make the whole function already six times as fast:

10.9 msecs per iteration (total: 109, iterations: 10)

The main difference is that the Q_ARG(QObject *) is not normalized,
something we should take a look out for. Furthermore this seems to
depend on the number of arguments, doing the same in connectionAdded
does not bring as much of a bonus as here.
Also add a benchmark for ConnectionModel's connectionAdded.

The numbers are on my machine in RelWithDebInfo:
     23.5 msecs per iteration (total: 235, iterations: 10)
Fix typo
--debug
Don't create a copy of the signature to find the meta method.

Instead operate directly on const char* and use pointer increment
to skip the signal/slot code char at position 0.

The connectionModel_connectionAdded benchmark shows the improvement:

Before:
     22.96 msecs per iteration (total: 2,296, iterations: 100)

After:
     19.71 msecs per iteration (total: 1,972, iterations: 100)
Optimize ConnectionModel: Cache normalized methods/signals signatures.

This helps in two ways. On one hand, we save memory as we essentially
intern the normalized signatures. Furthermore we save the apparently
not-as-cheap-as-though call to QMetaObject::normalizeSignature after
we normalized the signature once. The bench suite shows a big gain:

RESULT : GammaRay::BenchSuite::connectionModel_connectionAdded():
     12.39 msecs per iteration (total: 1,239, iterations: 100)
RESULT : GammaRay::BenchSuite::connectionModel_connectionRemoved():
     6.25 msecs per iteration (total: 626, iterations: 100)

Before these numbers were:

RESULT : GammaRay::BenchSuite::connectionModel_connectionAdded():
     21.19 msecs per iteration (total: 2,120, iterations: 100)
RESULT : GammaRay::BenchSuite::connectionModel_connectionRemoved():
     10.84 msecs per iteration (total: 1,085, iterations: 100)

This is a bit flawed, as the benchmark is a bit artificial and only
uses one signal and one method name. Still, note that those are
already normalized in the unit test and we still are much faster.

Evaluating cache hits/misses over a KDevelop run shows that this
is quite effective. We end up with 1672 entries in the cache which
equals the amount of cache misses. The cache was hit 149809 times
though, so a cache hit/miss ratio of 89.6, which is very good.

So this improvement should be valid and noticeable in real-world
applications as well.
Fixup the connectionRemoved unit test, it cannot be repeated.

I fall into that trap far too often... QBENCHMARK will repeat a unit
test, but you cannot re-initialize it. Thus the more often you repeat
the test, the worse off will be the per-iteration counts be. Since:
After you removed all connections one, you can repeat this step for
nearly no cost, thus skewing the numbers.

So instead use QBENCHMARK_ONCE and increase the test-length by other
means. We now also test non-normalized and invalid connects. Also
we increase the number of objects. New numbers are:

     294 msecs per iteration (total: 294, iterations: 1)
Qt4: Optimize removal of connections.

QVector in Qt4 does not move objects when erasing, even though
Connection is marked as movable. To workaround this issue, we
swap with the last entry and pop from the back which is cheap.

New benchmark data is (twice as fast):
     131 msecs per iteration (total: 131, iterations: 1)

More importantly though, the shutdown of KDevelop in GammaRay with
~60k entries in m_connections is much faster compared to before.
Optimize: Similarize ConnectionModel::connectionAdded to ...Removed.

This does improve performance after all, the benchmark now shows
these numbers on my machine:

     4.25 msecs per iteration (total: 425, iterations: 100)

Perf stat counts 3,530,400,790 instructions on the same benchmark.
Before that was in the range of 8,500,000,000.
Add objects to the probe.

Otherwise they are considered invalid in the ConnectionModel and
their connections never registered. Thus the whole benchmark was
broken.

So, proper numbers before I started working on the connection model
are as follows:

RESULT : GammaRay::BenchSuite::connectionModel_connectionAdded():
     61.64 msecs per iteration (total: 6,165, iterations: 100)
RESULT : GammaRay::BenchSuite::connectionModel_connectionRemoved():
     2,022 msecs per iteration (total: 2,022, iterations: 1)

After my optimizations we are down to:

RESULT : GammaRay::BenchSuite::connectionModel_connectionAdded():
     19.55 msecs per iteration (total: 1,956, iterations: 100)
RESULT : GammaRay::BenchSuite::connectionModel_connectionRemoved():
     61 msecs per iteration (total: 60, iterations: 1)
Add benchmark for Probe::objectAdded.

On my machine in RelWithDebInfo mode this yields:

RESULT : GammaRay::BenchSuite::probe_objectAdded():
     118 msecs per iteration (total: 118, iterations: 1)
Optimize ObjectTreeModel for cases where we have many sibling objects.

Again we keep our sibling list sorted and thus stay at O(log(n)) and
never have to resort to O(N) lookups, especially for indexForObject
which is called frequently.

RESULT : GammaRay::BenchSuite::probe_objectAdded():
     77 msecs per iteration (total: 77, iterations: 1)
Use normalized Q_ARG to save allocations.
Properly guard access to checkMethodForObject with objectLock.

This is required for objects from the background thread, as they
otherwise might get deleted while we check the validity of a
signal/slot connection.

This was previously not required as we ran the validity check in
the thread where the connection was created, but now that we
optimized the signal-slot normalization in the main thread, we must
pay special attention here.
Remove obsolete code