Also only watch folders not files.
That also removes files that are directly listed in INSTALLS /
DEPLOYMENT, I'll readd them in a later commit.

Use the full path for folders to sort in the project tree.

For virtual folders ensure that the path ensures the sorting we want.

Reviewed-By: kkoehne

 * 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

We create a .sis package per leaf project now, deploy all of them and
start the executable for the runconfiguration that was selected. This
does not cover all use cases, but works for development.

 * 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).

that way the users don't have to duplicate the connect everywhere.
as a side effect, MaemoPackageContents will have error reporting now.

the message manager is not thread-safe, so don't use it outside the main
thread.

Task-Nr: QTCREATORBUG-1593

 * 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: con
Reviewed-By: Friedemann Kleint

We now support renaming files. The version control system tries first to
rename, if that doesn't support or can't rename the file we do a normal
rename. (Note: git, hg, perforce > 2009.02 support renaming, cvs not.
(perforce untested)). We correctly notify all editors of the renamed
file and tell the project manager to rename the file in the project.

Note: Only the qt4projectmanager knows how to rename files.

Note: renaming folders, moving files to different folders, renaming
.pro/.pri files is not supported. Those things can be later added after
this has proven to work correctly in the simple case.

Also we don't do any actions based on the renaming like renaming
classes, changing include guards or #include lines.

Task-Nr: QTCREATORBUG-1151

Reviewed-by: dt

... use it.

Reviewed-by: dt

Reviewed-by: dt

The functionality was duplicated between the Qt4 and CMake build
configurations and their configuration widgets. This change moves it
down to BuildConfiguration, in addition also making it available for the
Generic Project.

Also provides an upgrade path for the configuration.

Task-number: QTCREATOR-24
Reviewed-by: dt
Reviewed-by: Tobias 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

 * Not good, but better than ASSERTing/crashing later on.
 * Use a qWarning to provide some hint on what is going on.

 * 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.