Revise the install_name_tool machinations in the light of experience with the
Terf plugins and examination of e.g. Xcode,app. When including dylibs from
elsewhere in Contents/Frameworks they should have an id of @rpath/foo.M.dylib
and access any dylibs they load from Contents/Frameworks should also be named
@rpath/bar.N.dylib, etc. Likewise the executable should include an rpath
for Contents/Resources (we'd like it to be Contents/PlugIns but this seems to
break something), and Contents/Frameworks. It turns out that Xcode.app uses
both @executable_path/../Frameworks & @executable_path/../PlugIns. We're close
but not quite there yet.
Add similar debug printing to tryLoadingLinked as is in tryLoadingInternals.