explore solutions to RPATH being present in precompiled extensions

[flavorjones]

draft PR to explore solutions to #3133

What problem is this PR intended to solve?

Have you included adequate test coverage?

Does this change affect the behavior of either the C or the Java implementations?

[flavorjones]

Iteration 1 was to skip setting $LIBPATH in the extconf, which results in failures on platforms that need to find libz, as well as when --disable-static is used.

https://github.com/sparklemotion/nokogiri/actions/runs/7995462149?pr=3137

[flavorjones]

Iteration 2 was to set $LIBPATH to an empty array right before generating the Makefile, so that intermediate libraries (libxslt, libxml2) could build against libz, but then the final nokogiri.so would link statically. However, this fails because it uses shared libraries for libz and does not statically link as we desire.

https://github.com/sparklemotion/nokogiri/actions/runs/7995800240/job/21837134836

This issue is closely related to the set of challenges described in flavorjones/mini_portile#118 and which remain unfixed. I need to do some more thinking about how mini_portile and/or rake-compiler-dock can and should support better behavior to support statically-linking these libraries; ideally when statically-linking a DLL the RPATH should be empty.

There's one more thing I will try, which is to run patchelf within the rake-compiler-dock container after linking Nokogiri's extensions, which addresses the symptom locally.