Reviewed-by: Thomas Hartmann

Reorder arguments passed to QMake so that "-after" arguments happen
after the CONFIG was set on Symbian. Otherwise CONFIG is considered
to be a -after-argument itself!

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

Reviewed-by: dt

This allows us to enable/disable the experimental observer, independent
from the core javascript-debugger functionality.

Reviewed-by: Christiaan Janssen

Adapt Qt4ProjectManager to use QMLOBSERVER instead of QMLINSPECTOR
(got changed in commit a10b2692)

e.g. DEFINES+=bla on the qmakestep command line now work

Task-Nr: QTCREATORBUG-2091

 * Enable support for this in all ProjectConfiguration items
   (Targets, projects, BCs, DCs, RCs, etc.). This is nicer
   than having custom code in individual configuraiton items.

Reviewed-by: dt

 * Add test for build- and sourcedirectories being at different levels

Reviewed-by: dt

 * Report what kind of build we have in the tooltip
 * Create only debug/release configuration for debug/release
   configured directories
 * Create debug and release configuraions for debug_and_release
   configured directories
 * Add debug_and_release to options in QMakeStep UI
 * Do not add CONFIG+=debug/release to CONFIG+=debug_and_release builds

Instead of hardcoding a Qt Creator path into the standalone Qml
app .pro file by assigning a value to QMLINSPECTOR_PATH, we let
Qt Creator set that value as command line argument when calling
qmake.

QMakeStep::allArguments() is the place where it is added right
dt will will certainly suggest a better place place for it.

 * Add a DeployConfiguration class to hold settings related
   to deployment.
 * Add BuildStepsList to hold a list of buildsteps
 * Update BuildConfiguration to use BuildStepLists instead of
   manageing lists of buildsteps itself.
 * Update BuildManager to use BuildStepLists in its interfaces
 * Fix fallout introduced by API changes
 * Update .user file to new way of storing settings

Task-number: QTCREATORBUG-1427
Task-number: QTCREATORBUG-1428
Task-number: QTCREATORBUG-1811
Task-number: QTCREATORBUG-1930

This changes the colors to be a mix of red/blue and the foreground
color. If the regular text color is either of those, well...

 * Move and rename the enum
 * Add Q_ENUMS macro

Reviewed-by: dt

Is more then twice as fast

The symbian makefile generator don't support shadow builds. Thus they
always pollute the source directory with build artefacts. Mixing
in-source and shadow builds is obviously broken.

We do as good as we can, setting OBJECTS_DIR, MOC_DIR, UI_DIR, RCC_DIR
to .obj, .moc, .ui and .rcc, which keeps the source dir clean of at least
some of the artefacts. This is as good as we can, but not really good.

Task-Nr: QTCREATORBUG-1293
(cherry picked from commit 33ef722b)

The symbian makefile generator don't support shadow builds. Thus they
always pollute the source directory with build artefacts. Mixing
in-source and shadow builds is obviously broken.

We do as good as we can, setting OBJECTS_DIR, MOC_DIR, UI_DIR, RCC_DIR
to .obj, .moc, .ui and .rcc, which keeps the source dir clean of at least
some of the artefacts. This is as good as we can, but not really good.

Task-Nr: QTCREATORBUG-1293

Reviewed-by: dt

 ... if it is part of the drive letter only.

This is needed to enable additional checks on the result.

Reviewed-by: dt

If SDK and Project were on te same drive but for some reason the drive
in the pathes had different cases, we had false alarms.

Made the comparision case insensitive as agreed with Tobias.

Reviewed-by: Tobias Hunger

It was searched in /include/stdapis/string.h

Added the /epoc32/ as agreed with Tobias.

Reviewed-by: Tobias Hunger

Tested on OSX, otherwise qmake will automatically append -macx which
results in Makefiles containing references to the host Qt libraries,
e.g. -lQtCore_debug etc...

Reviewed-by: dt

 * Check for symbian SDK and soureces being on the same drive on windows
 * Check for a Open C/C++ header in Symbian SDK and warn if that is not found
 * Check for chars in project name that might confuse symbian SDKs

Task-number: QTCREATORBUG-1045
Task-number: QTCREATORBUG-1043
Reviewed-by: dt

That is e.g. buildSteps() and cleanSteps() --> steps(type)

 * Do not use the BuildManager but have the qmakestep trigger
   the update via the target and project.

Reviewed-by: dt

 * Ease cross device development by introducing 'targets' which
   group build- and runsettings that are valid for this one target

 Most of the kudos for the code review go to dt. Con, thorbjorn,
 ckandler and others did also review parts of this patch.

Reviewed-by: dt

 * Use new BuildSteps interface (as seen in ProjectConfiguration).
 * Use new factory to construct/clone/restore them.

Reviewed-by: dt

They do what you expect them to do, that is build only a subtree.
The implementation is a little bit strange. We temporarly set the sub
node to be built on the BuildConfiguration, enqueue that
BuildConfiguration (which calls BuildStep::init()), and then reset that
temporary value.

A more general way would be to have the ability to extend
BuildConfiguration::buildProject() in a way that additional data can be
passed to the BuildSteps.

Task-Nr: QTCREATOR-5
Task-Nr: QTCREATORBUG-44

Task-Nr: QTCREATOR-269

Instead note that it is invalid if trying to build and on the projects
mode pane.

Task-Nr: QTCREATORBUG-459

  * Use id() for methods returning a string used to represent
    some type of object.
  * Use displayName() for strings that are meant to be user
    visible.
  * Quieten some warnings while touching the files anyway.
  * Move Factories to their products in the plugins where that
    was not done before.

Reviewed-by: dt