This has still a few missing things, but this enough to start getting
some feedback. Missing are non qt projects, a solution for the
runconfiguration, a missing black line between the treeview on top and
the project settings at the bottom. Some flickering with removing/adding
widgets to the QScrollArea and not showing the expanded widget if the
Details button is right at the bottom.

Don't add -spec foo to the additional Arguments if foo is the same as
the default mkspec. This makes the common case better, while breaking if
you have QMAKESPEC set in teh environment and used -spec foo to override
it.

I need that in the Qt4ProjectConfigWidget to decide whether I should
show a import label.

We add each command line argument to the Additional Arguments

Create a new one and check if it's the same as the old one,
has the advantage that cached data doesn't need to be retrieved again.
It was that way before tool chain was moved to Qt4Project.

E.g. cmake pops up a wizard then, the running of cmake can fail though.
Now you don't end i[ with a empty project then. The error reporting in
that case is not yet optimal.

And if Qt version changed.

Transform the method in Qt4Project into a signal that is handled
by the run configurations themselves.

QtVersion provides possible toolchains that can be used by the
Qt version, e.g. winscw, gcce and armv5 for symbian-abld.

Reviewed-by: Trust Me

Conflicts:

	src/libs/cplusplus/CppBindings.cpp
	src/libs/cplusplus/CppBindings.h
	src/libs/cplusplus/FastPreprocessor.cpp
	src/libs/cplusplus/FastPreprocessor.h
	src/plugins/cpptools/cppcurrentdocumentfilter.cpp
	src/plugins/cpptools/cppcurrentdocumentfilter.h
	src/plugins/cpptools/cppsemanticsearch.cpp
	src/plugins/cpptools/cppsemanticsearch.h
	src/plugins/duieditor/parser/qmljs.g
	src/plugins/duieditor/parser/qmljsast.cpp
	src/plugins/duieditor/parser/qmljsast_p.h
	src/plugins/duieditor/parser/qmljsastfwd_p.h
	src/plugins/duieditor/parser/qmljsastvisitor.cpp
	src/plugins/duieditor/parser/qmljsastvisitor_p.h
	src/plugins/duieditor/parser/qmljsengine_p.cpp
	src/plugins/duieditor/parser/qmljsengine_p.h
	src/plugins/duieditor/parser/qmljsgrammar.cpp
	src/plugins/duieditor/parser/qmljsgrammar_p.h
	src/plugins/duieditor/parser/qmljslexer.cpp
	src/plugins/duieditor/parser/qmljslexer_p.h
	src/plugins/duieditor/parser/qmljsmemorypool_p.h
	src/plugins/duieditor/parser/qmljsnodepool_p.h
	src/plugins/duieditor/parser/qmljsparser.cpp
	src/plugins/duieditor/parser/qmljsparser_p.h
	src/plugins/duieditor/parser/qmljsprettypretty.cpp
	src/plugins/duieditor/parser/qmljsprettypretty_p.h
	src/plugins/duieditor/rewriter/rewriter.cpp
	src/plugins/duieditor/rewriter/rewriter_p.h
	src/plugins/duieditor/rewriter/textwriter.cpp
	src/plugins/duieditor/rewriter/textwriter_p.h
	src/shared/cplusplus/ASTClone.cpp
	tests/manual/cplusplus/main.cpp

Reviewed-by: Trust Me

Note: as for qt projects, this is also used for running. And we don't
use it for running cmake yet.

Makes the code nicer, we use the ProFileReader to parse the mkspec.

This means, creating a new project, we immediately have completion for
the ui file. Also adding stuff to the ui file now changes the codemodel
immediately.

Yet todo, are tests under windows and suppressing a warning if the form
contains a toplevel spacer.

This is a step towards fixing Task: 243747

Qt Creator wouldn't find the correct target if shadow building a project
that uses $$OUT_PWD, like for example itemviews-ng.
We didn't set the necessary variable on the ProFileReader *, simplified
the code to always use a ProFileReader created for the exact
profilenode.

After all I don't need all that stuff in the cmakeplugin, all i needed
is now bundled in debugginghelper.h/cpp

The Debugger, cmake and Qt4 plugin all need it. More refactoring to it
coming.

The name is used as the base for files like [project].creator,
[project].files, etc. and is displayed in the Projects mode and the
Projects tree.

Task:     247606
Details:  Remove all the magic which build on top of the cumalative
parser. Instead trust the exact parsing to get those variables correct.
This required a bug fix in the profile evaluator, done with ossi.
Hopefully this doesn't break windows/mac. Will check.

Details:  Move that code from qt4project to a common class.

Details:  These classes replace a number of classes with differing
interfaces by just one class. The design isn't quite perfect, but a lot
better than what it used to be. Also moved the ToolChain classes to the
projectexplorerm so that eventually the cmake plugin can also use them.

Details:  This should improve performance a bit. Instead of starting on indexer per .pro file, schedule and compress updates of ui files. And don't update if we have a full project code model update scheduled anyway. Which helps the startup case.

Details:  Free the whole ProFile*, ProItem*, ProValue* and etc
structure after parsing, that frees around 200Mb for projects.pro.

Details:  ProFileCache be gone, as is ManagedProFile, not to be missed.
Drastically simplified how ownership works.