BUG: Don't add '.' to PATH, LD_LIBRARY_PATH, etc.

Modify ctkAppLauncherInternal::buildEnvironment to only append paths to
environment entries if the current path list is non-empty. This prevents
adding an implicit '.' entry to the list (in the form of an empty
entry), which is both undesirable (and probably unintended) and
represents a possible security risk.
STYLE: Refactor platform conditionals

Change preprocessor logic to select platform specific code to
consistently use the Qt OS symbols, to treat all non-Windows platforms
as POSIX, and to explicitly fail (i.e. '#error') in case of an unknown
platform. This simplifies the preprocessor logic and produces a better
error in case of an unsupported platform (which previously would have
failed due to use of unknown variables).
STYLE: Simplify building path lists

Remove unwound list concatenation code and replace with use of
QStringList::operator+(QStringList). This simplifies the code
considerably.
ENH: Support additional path list envvars

Add support for an additional list of environment variables that should
be treated as path lists. Add ability to specify these as lists in the
manner of [Paths] and [LibraryPaths] (which are merged with any values
set in the "traditional" manner for backwards compatibility). Refactor
buildEnvironment to treat PATH and the platform-appropriate library path
in the same manner as these (which greatly simplifies the code).

Besides the added convenience in the configuration file, the generated
wrapper script now also prepends to these variables as well as the usual
PATH and library path variables.
BUG: Don't add '.' to paths via wrapper script

Fix bug in generation of the wrapper script which unconditionally adds
the previous environment paths, resulting in an empty entry (i.e. an
implicit '.') if the variable was not previously set. This avoids a
potential security issue, though it requires using the somewhat esoteric
'${VAR:+:$VAR}' syntax to append the existing value.

This is related to 65531307251f, but affects only the wrapper script, as
opposed to --launcher-dump-environment or the actual launch environment.

Note that this doesn't work on Windows, but since Windows searches the
current directory anyway (at least for PATH), we can live with that for
now.
STYLE: Make ctkAppLauncherConfigure a function

Change ctkAppLauncherConfigure from a macro to a function. This appears
to have no effect on functionality, except that we no longer leak our
local variables into the parent scope (which is good, and the reason to
make the change).
ENH: Add --launcher-show-set-environment-commands

Add a new option that is somewhere between the existing 'dump
environment' and 'generate wrapper script' options to write (to stdout)
a series of commands to set up the launch environment. This is intended
to be usable like 'eval $(app --launcher-show-set-environment-commands)'
from a POSIX shell in order to modify the caller's environment.

To support this, refactor generateExecWrapperScript to separate out the
common code, which now writes to a QTextStream, and to write directly to
the output script directly (facilitating use of the new method) rather
than to a QStringList.
BUG: Fix quoting of environment variables

Modify generateEnvironmentScript to properly quote environment variables
(introducing a helper method for this purpose) - specifically, to
correctly escape special characters (e.g. quotes, the escaping
character) rather than just blindly slapping quotes around the string -
in order to avoid problems in case a path contains such characters.
STYLE: Avoid gratuitous stack variables

Now that we are using named string literals for our format strings, give
them static storage, as there is no reason to use stack storage for
them.
BUG: Make environment commands actually work

Fix subtle bug dumping environment commands; in order for 'eval' to
recognize distinct commands, they must be separated by ';'... just
separating by newlines is not enough.
BUG: Fix problem when no extra paths set

Launch configurations will likely store an empty list of additional path
variables as an empty value. However, this is converted to a list
containing an empty string, which makes ctk::readArrayValues unhappy
when asked to read entries for a list with an empty name. Therefore,
only consider the name if it is non-empty.

See also https://bugreports.qt-project.org/browse/QTBUG-19823.
Merge branch 'improve-environment-manipulation' into improve-environment-manipulation-update

Incorporate latest master in order to resolve test failures
that we will otherwise introduce due to the recent merge of
'test-cmake-generate-launcher-config'.

* improve-environment-manipulation:
  BUG: Fix problem when no extra paths set
  BUG: Make environment commands actually work
  STYLE: Avoid gratuitous stack variables
  BUG: Fix quoting of environment variables
  ENH: Add --launcher-show-set-environment-commands
  STYLE: Make ctkAppLauncherConfigure a function
  BUG: Don't add '.' to paths via wrapper script
  ENH: Support additional path list envvars
  STYLE: Simplify building path lists
  STYLE: Refactor platform conditionals
  BUG: Don't add '.' to PATH, LD_LIBRARY_PATH, etc.
BUG: Resolve test failures

Resolve failures in new tests that were added by the
'test-cmake-generate-launcher-config' branch, that are broken by changes
on this branch.
ENH: Add unit tests for additional paths feature

Modify the new configure unit test from the other branch to also test
the new additional paths feature. Modify the TestEnvironment unit tests
(and the test application) to also test the same.

Note that TestEnvironment-NotFound actually had another bug that is now
fixed; the third expected value name was wrong, and was thus not
expanding, and as a result we never actually tested the value. The new
regex has an additional trailing newline that will prevent that sort of
thing from happening (as long as the value doesn't start with a newline,
anyway).
Merge pull request #41 from mwoehlke-kitware/improve-environment-manipulation

Improve environment manipulation

Tested on Ubuntu 13.10 on a Debug build.
```
100% tests passed, 0 tests failed out of 53
```