If building FDO with internal openssl/libcurl, building libcurl insists on linking to system openssl instead of internal copy

[jng]

I've been observing when doing a full end-to-end build of FDO with all internal libs on Linux that when it comes time to build Utilities/OWS, it fails with linker errors around OpenSSL.

When I look at the build logs, I see that libcurl's configure picks out the system-installed version of OpenSSL instead of the internal copy.

The system-installed OpenSSL slipped in as an indirect dependency of one or more packages that needed to be installed to set up the build environment, so not having default OpenSSL present is not an option.

[jng]

In 7825:

If you are building the internal libcurl, chances are very high that you also built the internal openssl as well.

But the current build script as-is, will not build/link to this copy if a system-provided version is present due to libcurl's configure script having a strong preference for a system-installed version of openssl unless told otherwise.

This commit updates the build.sh to make sure that libcurl is built/linked against the internal copy of openssl, which addresses downstream problems where building of Utilities/OWS fails due to libcurl/openssl linker errors as a result of this mismatch.

Fixes #967

[jng]

Premature celebration :( System OpenSSL is still playing interference

[jng]

In 7826:

The previous attempt to get libcurl to build against internal openssl didn't work because internal openssl does not produce an installation layout that can be directly recognized by the --with-ssl switch for libcurl's configure script. This commit configures openssl to install to the "_install" directory. The build.sh of libcurl will invoke configure with this directory for --with-ssl if it exists.

Also the cmake_bootstrap.sh builds libcurl before openssl, which is the wrong order. So that is fixed as well.

Fixes #967 for real