Shared object test: make the shared object locatable on Darwin

[chrisnovakovic]

On Darwin, the linker links a library dependency by recording the path given in the library's install name (i.e. in the LC_ID_DYLIB load command) in the dependent executable. By default, this is the absolute path of the dependency when it itself was linked, which only exists for the lifetime of the Please sandbox for the build action that originally built the dependency - Please relocates the library elsewhere after building it. This prevents dyld from identifying it as the library it should load when the dependent executable starts, as demonstrated by the current current shared object test, in which dyld fails to locate libdolphin when running the test binary:

bash-3.2$ pwd
/Users/runner/cc-rules/plz-out/tmp/test/so/so_test._test/run_1

bash-3.2$ otool -D test/so/libdolphin.so
test/so/libdolphin.so:
/Users/runner/cc-rules/plz-out/tmp/test/so/libdolphin._build/libdolphin.so

bash-3.2$ otool -L $TEST
/Users/runner/cc-rules/plz-out/tmp/test/so/so_test._test/run_1/so_test:
        /Users/runner/cc-rules/plz-out/tmp/test/so/libdolphin._build/libdolphin.so (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.151.0)

bash-3.2$ $TEST
dyld[17867]: Library not loaded: /Users/runner/cc-rules/plz-out/tmp/test/so/libdolphin._build/libdolphin.so
  Referenced from: <7EF89393-48F0-316B-B09A-2F32F324F1BB> /Users/runner/cc-rules/plz-out/tmp/test/so/so_test._test/run_1/so_test
  Reason: tried: '/Users/runner/cc-rules/plz-out/tmp/test/so/libdolphin._build/libdolphin.so' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/runner/cc-rules/plz-out/tmp/test/so/libdolphin._build/libdolphin.so' (no such file), '/Users/runner/cc-rules/plz-out/tmp/test/so/libdolphin._build/libdolphin.so' (no such file)
Abort trap: 6

Instead, record an install name in libdolphin that is relative to @rpath, which dyld evaluates at run time based on the rpath stamped into the test binary at link time:

bash-3.2$ pwd
/Users/runner/cc-rules/plz-out/tmp/test/so/so_test._test/run_1

bash-3.2$ otool -D test/so/libdolphin.so
test/so/libdolphin.so:
@rpath/libdolphin.so

bash-3.2$ otool -l $TEST | grep -B1 -A2 LC_RPATH
Load command 17
          cmd LC_RPATH
      cmdsize 40
         path @executable_path/test/so (offset 12)

bash-3.2$ otool -L $TEST
/Users/runner/cc-rules/plz-out/tmp/test/so/so_test._test/run_1/so_test:
        @rpath/libdolphin.so (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.151.0)

bash-3.2$ $TEST

bash-3.2$ echo $?
0

This allows dyld both to locate libdolphin on the filesystem and to identify it as the library it needs to load, and makes dynamic loading work on Darwin more like the way it does on Linux and FreeBSD, where a dependency is located via its leaf file name in an rpath either stamped into the dependent executable or a predefined path known to the loader.

We may want to abstract away this complexity into the cc_shared_object and cc_binary/cc_test build definitions at some point, although if we do that we should do it consistently across platforms in a way that is likely to broadly satisfy all users (which is tricky).