Release: Temporarily exclude ExternalProject test on cygwin

Only temporarily until we can setup a new cygwin build machine
for making releases. It's specific to the script that runs on
dash2win64 anyhow. When we add a new script to run it on a
different machine, and stop building the cygwin releases on
dash2win64, this change will naturally no longer apply.
Add ability to run as a ctest -S script also

Then, use ctest_sleep to separate uploads by at least one
second each, so that the files on the web server all get
distinct time stamps.

Then, when viewed on the web server, sorted by time, they
are also sorted alphabetically.
Use OUTPUT_NORMAL instead of OUTPUT_MERGE for cmake -E chdir.

Using OUTPUT_MERGE can cause the output to be jumbled in some cases.
find_library: Add test covering lib->lib64 cases

Add a "CMakeOnly.find_library" test covering various cases involving
lib->lib64 (non-)conversion.  Comment out cases involving mixed path
components "lib" and "lib64", such as lib/A/lib64 and lib64/A/lib, as
these are known to be broken currently.
find_library: Refactor lib->lib64 conversion

Previously methods AddArchitecturePaths and AddLib64Paths were almost
identical.  Replace the latter with a call to the former.  Fix the
AddArchitecturePaths implementation to add trailing slashes to all
tested paths.
find_library: Simplify lib->lib<arch> expansion

Simplify cmFindLibraryCommand::AddArchitecturePaths logic to avoid
recording a separate 'found' status and populating an entire
vector<string> just to throw it away.
find_library: Fix mixed lib->lib64 (non-)conversion cases (#13419)

When a search path contains multiple "lib/" instances we previously
converted all or none.  This fails for cases where only some of the
multiple instances must be converted.  Teach AddArchitecturePaths to
generate all combinations that exist.  Uncomment these cases in the
CMakeOnly.find_library test now that they work.
remove lib64 Unix paths if the respective lib path is also given

If FIND_LIBRARY_USE_LIB64_PATHS is set both will be searched anyway.
Eclipse: add support for the 4.2 Juno release (#13367)

Thanks for the path to Nicholas Yue.

Alex
Eclipse: improve (fix ?) version detection on OSX

This is probably related to a framework installation I guess.
This is part of the patch in #13367 from Nicholas Yue.

Alex
Eclipse: fix #13358: don't create bad linked resources

Don't create linked resources which point to CMAKE_BINARY_DIR
itself or one of its parent dirs. Eclipse complained about that.

Alex
FindOpenSSL: find cross-compiled OpenSSL from MinGW (#13431)

Suggested-by: Dominik Schmidt <dev@dominik-schmidt.de>
FindOpenSSL: use SelectLibraryConfigurations
FindOpenSSL: let CMake handle environment variable HINTS

This will automatically make sure the paths will get recoded to proper separators on Windows
FindOpenSSL: cleanup path hints

-only use Windows-specific paths on Windows
-recode the contents of $ENV{PROGRAMFILES} to be a valid CMake path before
 using it
FindOpenSSL: remove leftover comment
SelectLibraryConfiguration: generate correct output when input vars are lists

In case that any of the input variables that hold the library names contains
more than just a single library the "debug" or "optimized" keywords were only
prepended to the first item, making all other libs appear in all
configurations. Just treat both input variables as lists.

Thanks to Philipp Berger <newsletters@philippberger.de> for pointing me at
this.
Fix typo direcotry -> directory (and similar) [#13444]
CMakeDetermine(C|CXX)Compiler: Consider Clang compilers

Look for "clang" or "clang++" compiler executables so Clang will be used
when it is the only compiler available.  Prefer them last to avoid
changing compiler default preferences for existing scripts.
Factor common code out of CMakeDetermine(ASM|C|CXX|Fortran)Compiler

The compiler candidate list selection and search code for C, C++, ASM,
and Fortran languages was duplicated across four modules.  To look for
compilers adjacent to already-enabled languages the C and CXX modules
each used _CMAKE_USER_(C|CXX)_COMPILER_PATH and the ASM module used
_CMAKE_TOOLCHAIN_LOCATION.  Since commit 4debb7ac (Bias Fortran compiler
search with C/C++ compilers, 2009-09-09) CMake prefers Fortran compilers
matching the vendor and directory of an enabled C or C++ compiler.

Factor out the common functionality among the four languages into a new
CMakeDetermineCompiler module.  Generalize the Fortran implementation so
that all languages may each use the vendor and directory of the other
languages that have already been enabled.  For now do not list any
vendor-specific names for C, C++, or ASM so that only the directory
preference is used for these languages (existing behavior).