Mostly Scott: More changes to the Windows Dependency builds

[Rod Widdowson]

I just want to give people (primarily Scott) the chance to comment on some changes I'll making in the C++ build tree.

To start with I should say that as far as XMLTooling is concerned I believe that we are reasonably well set for moving over to
OpenSSL 1.1.   I wrote several tests to try to force the changed code paths, and indeed had to fix a couple of bugs as a result.
There are a few bits which I haven't been able to test and I suspect that I will end up bench checking them or watching to see if
breakpoints get hit running under a full SP (for instance I have no idea how to write a unit test for the magic code to pull the
magic OpenSSL structure from a Curl connection and plug it into a magic Santuario Structure). 

Anyway it's time to loop back round and look at our dependency build, prior to starting on the next stage (latest version Visual C++
compilers).  One of the changes in OpenSSL1.1 was yet more changes to file names and paths.  It also raises the possibility of
changes our current process doesn't handle (e.g. headers which are different between Debug and Release builds).

So I took a step back from the build process we run and (eventually) discovered that we can get 99% of what we need by making one
change to the OpenSSL Configure script (to make the file names right for the debug case) and then building and installing . ("nmake
install_sw" )  [1]

This last stage allows you to put a "unix like" installation tree anywhere you want.  So rather than having directories inc32,
inc64, obj32, obj32.dbg, objx64, obkx64.dbg we have four directories (x86, x86Debug, x64, x64Debug) each with subdirectories  bin,
include & lib.

An immediate advantage of this is that it can be fed directly into the curl build environment that we are expected to use
(WITH_DEVEL=H:\....\openssl-1.1\x86Debug) [2]

Which leads on to the fact that this new curl environment also outputs its files to a different tree.

This means that downstream projects (Santuario and XMLTooling) now need to look for their inputs (headers and libs) in different
places.  So we come to the changes I will be making which is to add paths to the include and lib paths for Santuario (via the
externally injected file) and XMLTooling (via the Includes.props files).  Because I am just adding directories to paths this is
backwards compatible with the current way of building things.  

I'll note that file _name_ changes are much harder to deal with, but that ship has sailed because of the library name changes that
OpenSSL 1.1 imposes (libcrypto/libssl vs libesy32/ssleay32.)  The required chicanery to deal with that is already checked into those
files, the installer is TBD.

Finally I should say that I do feel that we should move over to this new way of building OpenSSL and curl - it is far easier to
automate and thus much less likely to cause problems.  I suggest that we do that when we move over to the latest Compilers (next
year sometime?)

Rod

[1] https://wiki.shibboleth.net/confluence/display/OpenSAML/OpenSSL#OpenSSL-Windows.OpenSSLVersions>1.1
[2] https://wiki.shibboleth.net/confluence/display/OpenSAML/libcurl