get away from argument stringlists. instead, use native shell command
lines which support quoting/splitting, environment variable expansion
and redirections with well-understood semantics.

Task-number: QTCREATORBUG-542
Task-number: QTCREATORBUG-1564

this is a wrapper around QProcess with these features:
- setEnvironment() takes a Utils::Environment instead of a QStringList
- instead of taking a stringlist with arguments, take a single shell
  command string which is fully compatible with the system's native
  shell (the bourne shell on unix and cmd.exe on windows) - with support
  for environment variable expansion, and subject to the shell's
  splitting and quoting rules. if the command is too complex (e.g.,
  contains redirections), it is transparently executed through a real
  shell.
- additionally, the class contains a set of helper functions for
  manipulating (constructing, splitting, etc.) shell command lines.
  in particular, it contains a shell-safe macro expander and the nested
  class ArgIterator which can be used for inspecting and manipulating a
  shell command line without going through the stringlist indirection
  (which is potentially lossy).

some of this is based on KDE code (KShell and KMacroExpander) which i
have written myself.

make it provide a macroExpander() instead of a resolve() function.
this detaches the actual variable management from the string
manipulation.

AbstractMacroExpander (any macros), AbstractQtcMacroExpander (%{var}
style macros, which is a hybrid of printf format specifiers and unix
environment expansions) and expandMacros() for the actual string
manipulation.

this is less confusing, because it doesn't look like an environment
variable expansion under unix.
the syntax is a hybrid of printf format specifiers and braced unix
variable expansions.

instead of being os-agnostic, interpret the os-native expansion style,
so it is consistent with proper (shell) command lines.

don't interpret quotes, as this function is meant for expanding isolated
filepaths, where nobody would expect quoting. instead, use the windows
style of simply not doing an expansion if a referenced variable is not
found, which should be good enough - it's rather unlikely that something
which happens to be an expansion of an existing variable is actually not
meant to be one.

(Instead of the initial system environment.)

Reviewed-by: kh1

(In QtCreator the wizard would take care of that.)

To keep the breakpoint state machinery simple

Task-number: QTCREATORBUG-3084

Task-number: QTCREATORBUG-2924
Reviewed-by: ck

Task-number: QTCREATORBUG-3090
Reviewed-by: ck

A full evaluate() call resolves the property and continues to the
underlying type. If we use Evaluate::reference() instead, we only the
first step is done and we can get at the source location if a
ASTPropertyReference is returned.

Reviewed-by: Erik Verbruggen

Task-number: QTCREATORBUG-2607
Reviewed-by: Erik Verbruggen

Reviewed-by: Erik Verbruggen

Reviewed-by: con

Reviewed-by: hjk
Task-number: QTCREATORBUG-3099

Task-number: QTBUG-15170

Clear controls that are not applicable to type, but save
and restore their value once the type is again choosen.