Add rpath for sharp-libvips in binding.gyp

[arcanis]

The rpath setting lists the path in which the linker should try to load the required dylibs. Paths are relative to the library, so with the current setting of:

'-Wl,-rpath,\'@loader_path/../../node_modules/@img/sharp-libvips-<(platform_and_arch)/lib\'',
'-Wl,-rpath,\'@loader_path/../../../node_modules/@img/sharp-libvips-<(platform_and_arch)/lib\'',

A library located in node_modules/pkg/lib/sharp/lib.node will try to find the libvips binary in the hoisted node_modules/@img/sharp-libvips-*/lib path, but not in the non-hoisted path node_modules/pkg/node_modules/@img/sharp-libvips-*/lib.

This PR adds the non-hoisted path to the rpath list so it properly locates the file when it's found as a direct dependency.

We stumbled upon this issue while attempting to solve in Yarn the root cause why you rely on Yarn-specific code.

[lovell]

Thanks for the PR Maël, is there an upstream issue related to this with more detail? Does this alleviate the need to include an rpath with the locator hash, or is this in addition?

(If you hadn't seen there are some packaging tests that include Yarn PnP. These only run/pass for each release, including release candidates, and are not used for PRs.)

[arcanis]

No upstream issue yet; I'm working on a new major in a separate repository, and it's when testing this release with our internal project that we noticed the breakage due to the new major having a different way to compute the hash.

While it's kind of a fringe case I feel like Sharp and similar tools shouldn't have to make assumptions about Yarn's internals, so I'm implementing a fix in that major so that Yarn will generate symlinks between packages when they're both unplugged.

[lovell]

Great, thank you for the explanation, that all sounds good. We can add packaging tests in the future specifically for yarn v5 PnP when it's released.