Untange kludgey library detection, particularly for SSL forks

Split from legacy/trac#13415 (moved):

teor:

LibreSSL

I'm having trouble getting LibreSSL (2.1.2) to work with tor git on OS X 10.9.

Here are the issues I've found and fixed in the configure invocation:

configure --with-openssl-dir= detects the wrong bin/openssl if "$OPENSSL_DIR/bin/openssl" isn't in the path before all other openssl executables.
configure --enable-static-openssl requires LDFLAGS="$OPENSSL_DIR/lib":$LDFLAGS to link properly, at least on OS X. 

I'm pretty sure these issues will affect all (non-system/non-standard) SSLs.

Can we make configuring with non-system SSLs easier by prepending "OPENSSL_DIR/bin" and "OPENSSL_DIR/lib" to the PATH and LDFLAGS respectively?

BoringSSL

BoringSSL is even worse - it doesn't even have an openssl executable, only builds static libraries, and is a pain to configure correctly under our current config scripts.

I can't seem to stop it finding the system-supplied SSL, even when I provide it the BoringSSL directories.

I get the following warnings when I manually install BoringSSL into include/lib/bin dirs, and fake the openssl executable using the bssl executable:

(See legacy/trac#13815 (moved))

nickm:

(The build issues are another matter and should get their own ticket: Untangling our kludgey library detection has been something a bunch of people have wanted for a while.)