* Make sure we have a display name set for targets when restoring
   from Qt creator 1.3.1 .user files.

 * 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

Reviewed-by: Tobias Hunger

 * 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

Using more *::Constants::ICON_* where it makes sense and
wrapping the file names into QLatin1String where they were
missing.

The increased usage of the ICON constants needed a few more
cross plugin includes of *constants.h, here and there.
I think that it is OK, since the dependencies were alredy there
icon resource wise.

 * Add buildstep to handle the deployment
 * Remove deployment code from the runconfiguration
 * Update .user files to add new deployment step into existing setups

Reviewed-by: Tobias Hunger

Reviewed-by: kh1

Doesn't do anything yet.

 * Add "Deploy" to BuildSteps::Type
 * Update UIs to handle deploy steps
 * Turn existing package creation steps from build type to deploy type
 * Move packaging steps into deploy steps when loading projects

Reviewed-by: dt

 * Move and rename the enum
 * Add Q_ENUMS macro

Reviewed-by: dt

 * Fix displayed shadow build location
 * Fix shadow build location used by newly set up shadow builds

Task-number: QTCREATORBUG-1599
Reviewed-by: dt
(cherry picked from commit 1d8e1760)

 * Fix displayed shadow build location
 * Fix shadow build location used by newly set up shadow builds

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

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

(No actual functionality yet.)

Reviewed-by: kh1

Reviewed-by: Roberto Raggi

This fixes a crash when creating a new target and then directly
switch into the run settings view.

 * Simplify code a bit, too.

* Allow for a more controlled setup of buildconfigurations inside
   the targets.

Reviewed-by: dt

Reviewed-by: dt

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

This is a big change touching almost all of our .pro file parsing.
With this patch we only evaluate once exact for all needs and once
greedy for the filelist. That is the qt runconfigurations don't have own
evaluaters but reuse the project wide exact evaluation.

We reevaluate if the user changes the build directory, the qmake
buildconfiguration or the qmake arguments. That is if you open src.pro
(or projects.pro) of qt with a shadow build you still don't get all the
files, but after correcting the build directory, we reevaluate the .pro
files and find all files. So for a suitable definition of fixed, that
bug is now fixed.

We now get the exact defines of all .pro files instead of all defines for all
buildconfigurations. We still don't distinguish in which
.pro file a DEFINE is set. So the code model now knows about all the
defines set for the given configuration but not for which files it is
actually set. Also that includes all DEFINES set in .qmake.cache or the
mkspecs. This means all defines from .pro files should now work.

The intial loading is still synchronous. I haven't looked into it to
deeply, but it seems possible to make it also async.There are probably a
few issues which need to be solved fist.

Also due to the asynchronous nature of the code, the executable is
updated a few seconds after actually changing the build configuration

 * kh1 says there is no such thing as there is no technical
   destinction between Maemo devices and the Maemo emulator.

Reviewed-by: kh1

 * Fixes RunConfigurations not updating when changing something
   in the BuildConfiguration.

Reviewed-by: dt

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

Reviewed-by: dt

...making use of a shared device by all clients. Detect device removal by
delaying the WM_DEVICE event handling. Introduce Acquire/Release mechanism
to SymbianDeviceManager and let acquire() fail if the device is in use, thus
preventing starting 'run' while debugging is active, etc.
Handle "Device removed" (unplugging of cable) signal by closing the device and adding
handlers to the clients, stabilize TrkDevice against it.
Remove communication type from the run configuration parameters (now handled by
SymbianDeviceManager).

Working towards keeping the Trk-connection always open and a giving the target pane
a meaningful tooltip.
For the moment, pass on tooltips from device manager additional information
(Trk version and such as determined by the launcher).

Since the target names are translated, we cannot use the saved
display name from the user file.

Reviewed-by: Tobias Hunger

thus fixing the exit warning:
"~QX11PixmapData(): QPixmap objects must be destroyed..."

Acked-by: con

Use that for showing details about connected Symbian devices.
Also update the icon with an (not-)connected overlay icon.
Graphics design pending.

 * 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