Make the global variable doReferenceCounting thread_local

I think that the second commit Make the global variable doReferenceCounting thread_local is quite safe. I am not nearly as confident about the third commit Make all DUChainReferenceCounting globals thread_local, which assumes a lot about the usage of DUChainReferenceCounting. See the commit messages for details.

No new kdevelop or kdev-python tests fail at the second or at the third commit.

Earlier benchmarks

I run each benchmark three times on master and the Make the global variable doReferenceCounting thread_local commit. All three results for both revisions are listed below:

Benchmark name          times on master (sec)   times with thread_local doReferenceCounting (sec)
bench_hashes            18.73, 18.50, 18.30     18.61, 18.67, 18.78
bench_itemrepository    2.32, 2.35, 2.33        2.34, 2.38, 2.35
bench_codecompletion    8.11, 7.96, 9.49        7.95, 7.93, 12.63
bench_duchain           5.70, 5.62, 5.00        4.96, 4.89, 4.96
bench_quickopen         14.56, 14.84, 14.77     15.03, 15.10, 15.23

bench_duchain seems to be faster now, but bench_quickopen - slower. I have no idea how thread_local could slow Quick Open down. So I run it five more times, but only on the 4th run it took less than 15 seconds: 14.48. Then I also run bench_duchain 6 times: 4.84, 5.85, 4.83, 4.81, 4.71, 4.79. Guess more detailed benchmark comparison is necessary to determine speedup/slowdown. But theoretically there should be no slowdown.

New benchmarks

I run each benchmark three times on master and the Make all DUChainReferenceCounting globals thread_local commit. All three results for both revisions are listed below:

Benchmark name          times on master (sec)   times with thread_local DUChainReferenceCounting class (sec)
bench_hashes            18.41, 18.18, 18.36     19.26, 19.27, 19.04
bench_itemrepository    2.04, 2.33, 2.33        2.39, 2.38, 2.38
bench_codecompletion    8.36, 7.64, 8.34        7.91, 7.99, 7.94
bench_duchain           4.93, 4.82, 4.87        4.95, 4.90, 4.68
bench_quickopen         14.48, 14.27, 14.57     13.93, 13.78, 13.35

Clearly, my earlier hypothesis that bench_duchain got slower is hereby proved wrong. bench_quickopen however seems to have become faster with the thread_local class DUChainReferenceCounting. This could be a consequence of the guaranteed absence of mutex locking and expensive checks in Quick Open's IndexedString usage. I run bench_quickopen three more times, and it is still clearly faster at the third commit than in master or in my previous benchmarks: 14.00, 13.64, 13.38. Now I run bench_quickopen on master and it matches the thread_local performance: 14.32, 13.73, 13.73. So this is clearly a random performance fluctuation.

bench_hashes seems to have become slower though. So I run it five more times at the apparently slowest Make all DUChainReferenceCounting globals thread_local commit. The results: 18.62, 19.08, 19.48, 18.89, 18.81. I have no idea how my changes slowed this benchmark down, but it does test IndexedString, so the impact is not implausible.