There is already a "CONFIG" in variables[] which always overshadowed
the entry from functions[].

I did not learn to count higher than 20, myself.

Task-number: QTCREATORBUG-1290

To be able to connect to them in the debugger namespace.
Reviewed-by: dt
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>

Also properly initialize m_projectContext in Qt4Manager, fixing the
disabled "Run QMake" action

 * Stop warnings about using QFileInfo without a proper filename.

   Turns out that the filename of the project can still be empty
   when calling these methods from the new project wizard (before
   the first page is done).

Reviewed-by: ck

Reviewed-by: ck

Reviewed-by: kh1

during the generation process and copy might fail afterwards.

Move open project dialog handling into ProjectExplorer and make it
use its list of project file patterns. Same in Checkout wizards.

Task-number: QTCREATORBUG-1759
Reviewed-by: dt

Cherry-picked from 2.0 branch.

Task-number: QTCREATORBUG-1670
Reviewed-by: ck

Task-number: QTCREATORBUG-1670
Reviewed-by: ck

Task-number: QTCREATORBUG-1748

DEPLOYMENT, ICON, TARGET.CAPABILITY, TARGET.EPOCHEAPSIZE and
TARGET.UID3

A mostly mechanical change.

Reviewed-By: con

we don't use anything the features may set up, so loading them just
wastes time. this may change if we start processing extracompilers
properly.

make it an argument of the main entry point instead of a property

 * Doubleclicking the directory in the targetsetuppage now
   switches between shadowbuilding (default) and in source
   building. Not very obvious, but then we do want to
   encourage people to use shadowbuilding.

Task-number: QTCREATORBUG-1668

I can't fully explain the backtrace, but connecting to
qtVersionsChanged() in ::init() and not the ctor is the correct thing to
do.

Task-Nr: QTCREATORBUG-1653
Reviewed-By: hunger

Task-number: QTCREATORBUG-1636
Reviewed-by: kh1

 * Update the Qt version combobox whenever the buildconfig signals
   that its Qt version changed.

Task-number: QTCREATORBUG-1692
Reviewed-by: dt

This replaces the (de facto) singleton engines and data handlers by classes
that are instantiated per run. The DebuggerRunControl will now create an
object of (a class derived from) DebuggerEngine that contains all the relevant
"dynamic" data.

DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin,
whereas the data bits went to DebuggerEngine.

There is no formal notion of a "current" DebuggerEngine. However, as there's
only one DebuggerEngine at a time that has its data models connected to the
view, there's still some "de facto" notion of a "current" engine. Calling
SomeModel::setData(int role, QVariant data) with custom role is used as the
primary dispatch mechanism from the views to the "current" data models
(and the engine, as all data models know their engine).

Task-number: QTCREATORBUG-1686
Reviewed-by: ck

Reviewed-by: kh1