KWSys: Make set<> ordering functor const

Address compilation error

 error C3848: expression having type 'const cmsys::kwsysEnvCompare'
 would lose some const-volatile qualifiers in order to call 'bool
 cmsys::kwsysEnvCompare::operator ()(const char *,const char *)'
Merge topic 'kwsys-environ-cleanup' into next

db1bfee KWSys: Make set<> ordering functor const
KWSys: Fix SystemTools environment memory handling (#13156)

The SystemTools::PutEnv function tries to provide the "putenv" API
without leaking memory.  However, the kwsysDeletingCharVector singleton
frees memory that may still be referenced by the environment table,
having been placed there by putenv.  If any static destruction or
processing by an external tool happens after the singleton is destroyed
and accesses the environment it will read invalid memory.

Replace use of putenv with setenv/unsetenv when available.  The latter
manage internal copies of the values passed instead of referencing the
original memory.  When setenv/unsetenv are not available use putenv with
a singleton that removes its values from the environment before freeing
their memory.  This requires an "unputenv" implementation.  On at least
some platforms it must be written in terms of "putenv" because other
APIs are not available and direct modification of the "environ" global
is not safe (e.g. on Windows there is interaction with "wenviron").
Fortunately either putenv("A=") or putenv("A") will remove "A" from the
environment on these platforms.  On other platforms fall back to direct
manipulation of "environ".

Also add UnPutEnv to the API and add a test for the behavior of both.
Merge topic 'kwsys-environ-cleanup' into next

e48796b KWSys: Fix SystemTools environment memory handling (#13156)
VS10: Refactor custom commands to use WriteSource

All other source file elements are already written through WriteSource.
Refactor custom command source element generation into WriteSource too.
VS10: Simplify vcxproj.filter file generation

Remove the duplicate source file classification logic used to generate
the filter files.  Instead record during the main vcxproj file
generation the source files generated for each tool.  Also record
whether or not each source file is converted to a relative path.  Use
the recorded result during filter generation to ensure consistency
between the project file and filter file.
VS10: Convert paths normally unless forced to relative

Most CMake generators produce relative paths within the build tree and
full paths to files outside the build tree.  Make VS 10 and VS 11
project files consistent with this approach except for paths forced to
be relative to work around a VS 10 bug.
VS11: Do not use source path conversion workaround specific to VS 10

CMake <= 2.8.4 generated VS 10 project files with a relative path to
source files.  Then commit ed0075bd (Use relative paths for custom command
inputs, 2011-06-22) switched to using relative paths only for source files
holding custom commands and full paths for other sources.  This behavior
was inhereted by the VS 11 generator but is not needed so use the
workaround only for exactly VS 10.  Explain the behavior in comments.
VS10: Generate relative source paths when possible (#12570)

Since commit ed0075bd (Use relative paths for custom command inputs,
2011-06-22) CMake generates full paths to source files in VS 10 project
files to avoid trouble with deep source/build tree paths.  However, the VS
10 IDE will not populate the source file property dialog for a file
referenced by full path.  Instead use a relative path when possible.  When
not possible produce a detailed warning explaining the problem and
suggesting use of shorter directory paths.
Merge topic 'vs10-source-paths' into next

d931ce9 VS10: Generate relative source paths when possible (#12570)
b2e7c7a VS11: Do not use source path conversion workaround specific to VS 10
4248132 VS10: Convert paths normally unless forced to relative
c2ba6ba VS10: Simplify vcxproj.filter file generation
4f2d9d2 VS10: Refactor custom commands to use WriteSource