Mostly Scott: More changes to the Windows Dependency builds

[Cantor, Scott]

I'll start looking at the Santuario work this month, with the caveat that I have no intention of releasing any of it until we need it. It's time people understand what "nobody is maintaining this software but us" really means.

> 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]

As bad as the OpenSSL build was, it was stil easier to fix up than curl, so anything that get curl done without a ton of screwing around works for me.

> 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.  

Santuario was always a problem because I didn't really want to check in changes to its solutions that depended on my customized OpenSSL build.

> 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?)

Yeah, we're still basically hung up on the 2.7 vs. 3.0 decision but I'm comfortable moving to the new compiler for a 2.7 release. The Apache thing is a concern I guess, but if we give notice, I think we can live with moving that to 2.4 only. We might have to provide extended support for 2.6 and Apache 2.2 though, through Dec 2017.

Or we might just prep the release to coincide with that date I guess. I'd rather we get some other stuff done for 2.7 anyway, and it might take that long.

-- Scott