Task-number: QTCREATORBUG-2073

 * 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

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

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

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

Task-Nr: QTCREATORBUG-1108
Task-Nr: TOOLS-339

... use it.

Reviewed-by: dt

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

Reviewed-By: hunger

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

 * If the qmake path does match then the target does match, too.

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

Reviewed-by: dt

 * Initialize it to the toolchain used, not the preferred one

 * Update the import label (and related stuff) whenever the
   project was rebuild.

 * 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

Reviewed-by: dt

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

Resetting the cursor to the end of line and resetting the line edit on
changing the shadow build checkbox

Should fix a lot of corner cases, might introduce a few bugs.
Also rename functions/slots to be better named.

Generic Project Manager and CMake Project Manager are missing from this
patch.

Also rename some methods/signal to make clearer that those only are
relevevant for user changes not for all arguments.

Fix for that will come later

Note: I didn't fix all the connects and there are a few missing things.
This compiles, more work is coming.

The pointers can be used to distinguish BuildConfigurations

Each project has it's own BuildConfiguarion * classes, they'll get a
decent type safe interface and the setValue/value stuff will be removed.

Separate category and trCategory and introduce sorting characters
to the categories. Same for id/name.