* 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

foreach()-Loops.

QString: Use QChar where appropriate.

 * That is what everybody else is using now.

Reviewed-by: dt

 * This makes it easier to distinguish projects in the
   userfileaccessor

Reviewed-by: dt

QMake passes those headers directly to gcc, so the user doesn't need to
include themselves.

Reviewed-By: con

Reviewed-by: thorbjorn

  * 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

This code was (more or less) duplicated in 4 places.

setClean(true) doens't imply a clean argument anymore. (To make it user
configurable.)

Reviewed-By: owolff

no point in re-parsing them over and over during the scan of a bigger
project ...

shaves off another 20% of the loading time of Qt 4.6.

there is no point in throwing away and re-recreating invariant data over
and over ...

shaves off ~15% of the load time of Qt 4.6.

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.

...making use of the new code model features. Move code to
separate file. Make it possible to obtain path to generated
header file from project manager.

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

The project() should in most cases not matter, instead the
BuildConfiguration should. This shows all the information that needs to
move into the BuildConfiguration classes.

More API work.

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

Enables users to change which buildsteps get run per buildconfiguration.
Some further tweaks are probably necessary. This is a rather big
change, though it should work. :)

Factor out the initialization setting up the environment and headers in
the RVCT/GCCE toolchains.
Modify the RunControl to be able to support different package
building/signing processes.