Add option to add an rpath to the produced binaries, enable rpath use for MacOS

During development I use many local OpenSSL builds in parallel with various active branches. Of course I do not install them, but then there is an issue with auto-locating libcrypto and the like. Among others, when trying to use such non-installed OpenSSL libs in other developments goes wrong. A related problem is referencing the right dynamic libs when calling OpenSSL apps in the internal tests. and there are likely also other use cases where this shows up.

For instance, ldd apps/openssl can give the following output highlighting the problem:

apps/openssl: /lib/aarch64-linux-gnu/libssl.so.3: version `OPENSSL_3.4.0' not found (required by apps/openssl)
apps/openssl: /lib/aarch64-linux-gnu/libssl.so.3: version `OPENSSL_3.2.0' not found (required by apps/openssl)
apps/openssl: /lib/aarch64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.3.0' not found (required by apps/openssl)
apps/openssl: /lib/aarch64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.4.0' not found (required by apps/openssl)
apps/openssl: /lib/aarch64-linux-gnu/libcrypto.so.3: version `OPENSSL_3.2.0' not found (required by apps/openssl)
	linux-vdso.so.1 (0x0000ffff83c85000)
	libssl.so.3 => /lib/aarch64-linux-gnu/libssl.so.3 (0x0000ffff83a40000)
	libcrypto.so.3 => /lib/aarch64-linux-gnu/libcrypto.so.3 (0x0000ffff83400000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff83890000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffff83c48000)

Basically the same output is given, e.g., by ldd libssl.so

On MacOS, the build system does not even recognise the OpenSSL installation I did in the usual way (brew install openssl@3), which happens to be good for using the local libraries. Yet even then (and maybe also on Linux in case no system-wide installation is found), depending on the --libdir config option, which defaults to lib there, the location goes wrong because the local lib files are in the OpenSSL build root dir, for instance /Users/david/O/openssl-3.0/ while the paths included in the binaries contain the local path ./lib, which typically does not exist. This is the output of otool -L libssl.dylib:

libssl.dylib:
	/Users/david/O/openssl-3.0/lib/libssl.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	/Users/david/O/openssl-3.0/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

All this is because the (r)paths placed in the lib and app binaries take into account assumed installation directories only. This leads to local non-installed lib instances not being found, or even worse, choosing wrong instances that may happen to be installed system-wide, which can lead to confusion and subtle reasons for crashes.

For helping find the non-installed OpenSSL dynamic libs, it is useful to add as config option: --prefix=$(pwd) and either add also --libdir=. or with default --libdir, place a symlink to this path: ln -s . lib In the latter case, in /Users/david/O/openssl-3.0 the output of otool -L libssl.dylib becomes

libssl.dylib:
         name /Users/david/O/openssl-3.0/./libssl.3.dylib (offset 24)
         name /Users/david/O/openssl-3.0/./libcrypto.3.dylib (offset 24)
         name /usr/lib/libSystem.B.dylib (offset 24)

This way, any applications needing the OpenSSL dynamic libs know where to find them, after generally pointing them to the local OpenSSL build dir to use.

The OpenSSL-internal test machinery works around this via util/shlib_wrap.sh, which fiddles with LD_LIBRARY_PATH and the like, depending on the OS etc.

Isn't there a simpler and more generally usable solution? Maybe by adding a extra rpath that reflects the actual location within the build root dir, which is .?