fix(shared-libs): improve dylib path resolver logic

This should handle edge cases where shared libraries are linked to as:

    @loader_path/../../../../opt/gettext/lib/libintl.8.dylib

In the above, `@loader_path` is replaced with the directory of the file
we're processing, so it would for example be expanded to:

    /opt/homebrew/opt/gnutls/lib/../../../../opt/gettext/lib/libintl.8.dylib

And because `File.expand_path` operates purely on the given input as a
string, it can only expanded it to:

    /opt/opt/gettext/lib/libintl.8.dylib

Which is clearly wrong. Hence we use `File.realpath` now which would
expand the above to:

    /opt/homebrew/Cellar/gettext/0.22.3/lib/libintl.8.dylib

This is because `/opt/homebrew/opt/gnutls` is a symlink to
`/opt/homebrew/Cellar/gnutls/3.8.1`, hence the `../../../..` relative
components operate against the real path, not the via the symlink path.

If `File.realpath` throws a `Errno::ENOENT`, it means the underlying
file does not exist, so we just fall back on the old behavior of using
`File.expand_path`. This should only really be relevant for macOS system
libraries and the like.

build-emacs-for-macos

@@ -1105,7 +1105,11 @@ class LibEmbedder < AbstractEmbedder
       fatal "Could not resolve path: #{path}" if abs.nil?
     end
 
-    File.expand_path(abs)
+    begin
+      File.realpath(abs)
+    rescue Errno::ENOENT
+      File.expand_path(abs)
+    end
   end
 
   def build_bundle_plan(macho_file, copy_macho_file: false)