SVN_SILENT made messages (.desktop file)
Fix support for moving files/folders in custom buildsystem

I was about to file a bugreport thinking its broken in
abstractfilemanagerplugin but it turns out that back when I created the
class I accidentally copied this function too. The implementation in the
abstractfilemanagerplugin should be sufficient, so lets just drop the empty
implementation.
Don't dump uninteresting info here
Properly parse C++11 reference bindings.

These are ignored in the semantic analysis for now but at least this
way code completion does not break and no annoying errors are shown.

BUG: 310472
Show actual AST size in the debug utility cpp-parser.

This is done by walking the tree and summing the size of the
encountered nodes.

The output is insofar interesting as it shows the discrepancy between
allocated memory and required memory of about 100% - i.e. we need
twice as much memory as the AST is actually needing. This is mostly
due to backtracking in the parser: When we encounter an invalid node
somewhere we might bubble up the parse chain and continue down a
different path. Any allocations in the memory pool are 'lost' this
way and not reclaimed until the whole pool is discarded.

We might want to think about reclaiming such nodes somehow. So far,
I did not come up with an easy, fast API to achieve this result
though...
Add a benchmark for the rxx_allocator.

This comes in two flavors:

1) A single pool and multiple allocations of 64 bytes. Somewhat
representative for the creation of the big AST tree.

2) Multiple pools with just a few allocations, as done by the
ExpressionParser.

Current results on my machine in RelWithDebInfo mode:

RESULT : TestPool::benchManyPools():
     0.039 msecs per iteration (total: 80, iterations: 2048)
RESULT : TestPool::benchManyAllocations():
     0.000068 msecs per iteration (total: 72, iterations: 1048576)
Introduce a thread local memory pool cache and refactor the code.

This optimizes the speed of our allocator, especially for the case
of multiple repeated constructions of memory pools as is being
done in the ExpressionParser. Funnily enough, I also managed to
increase the performance of the 'normal' operation for a single pool
with many allocations as is done in the full file parsing.

The way it works is that we keep a list of free, allocated blocks
around per thread. Right now, we keep up to 32 blocks of 64K around,
i.e. up to a total of 2MB per thread. This memory is only reclaimed
once the thread finishes. In KDevelop's case this means: never until
the app is closed. Still, I think up to 2MB per thread is not a big
deal and we could potentially decrease this.

Furthermore we should try to share these memory blocks between the
different language plugins. Right now most other lang plugins use
KDevelop-PG-Qt's allocator. I'll investigate how to change that.

New numbers are:

RESULT : TestPool::benchManyPools():
     0.0043 msecs per iteration (total: 71, iterations: 16384)
(approx 9x as fast as before)

RESULT : TestPool::benchManyAllocations():
     0.000038 msecs per iteration (total: 80, iterations: 2097152)
(approx 1.8x as fast as before)

For the expression parser benchmark the numbers are now:
RESULT : TestExpressionParser::benchEvaluateType():"global-int-number":
-     0.055 msecs per iteration (total: 57, iterations: 1024)
+     0.017 msecs per iteration (total: 70, iterations: 4096)
RESULT : TestExpressionParser::benchEvaluateType():"global-long-number":
-     0.056 msecs per iteration (total: 58, iterations: 1024)
+     0.018 msecs per iteration (total: 74, iterations: 4096)
RESULT : TestExpressionParser::benchEvaluateType():"global-long-long-number":
-     0.057 msecs per iteration (total: 59, iterations: 1024)
+     0.019 msecs per iteration (total: 78, iterations: 4096)
RESULT : TestExpressionParser::benchEvaluateType():"main-a.b":
-     0.074 msecs per iteration (total: 76, iterations: 1024)
+     0.035 msecs per iteration (total: 72, iterations: 2048)

The other benchmarks stay the same, mostly because they manage to
circumvent the need for a full text parsing and thus the allocator.

Also note: In both callgrind and perf the rxx_allocator::allocator
was a hotspot when looking at "duchainify path/to/kdevelop" and
that mostly due to the repeated calls to ExpressionParser for simple
one-word strings which still allocated a full block of memory. Now
this can be reused and thus operates faster. Saldy, timing the run
of duchainify though does not show any noticeable speedup.
Refactor and cleanup the rxx_allocator, rename it to MemoryPool.

The old code was stl compliant but that is never actually used in
our code. This new API is much simpler in my opinion and gets
the job done.
Extend gitignore file and ignore common profiling data
SVN_SILENT made messages (.desktop file)
Fix signal connections