$ORIGIN in $RPATH in nested dependency is not handled correctly

Nobody has claimed this yet.

When I try SPINDLE, I found that $ORIGIN in $RPATH in nested dependency is not handled correctly and the process cannot load some libraries.

Example: When my python script on my environment imports `matplotlib`,

1. matplotlib requires `/path/to/lib/python2.7/site-packages/numpy/core/multiarray.so`
2. Spindle create cache of multiarray.so as `/tmp/spindle.PIDNUM/b0-_path_to_lib_python2.7_site-packages_numpy_core_multiarray.so`
3. This multiarray.so requires `$ORIGIN/../.libs/tls/x86_64/libopenblasp.so`

In this case, `$ORIGIN/../.libs/tls/x86_64/libopenblasp.so` should be expands as `/path/to/lib/python2.7/site-packages/numpy/core/../.libs/libopenblasp.so`.
However, SPINDLE expands as `/tmp/spindle.PIDNUM/../.libs/tls/x86_64/libopenblasp.so`.

i.e. SPINDLE expands `$ORIGIN` as `/tmp/spindle.PIDNUM/` instead of `/path/to/lib/python2.7/site-packages/numpy/core/`

As a result, the process cannot load multiarray.so.

This issue may be similar to #17, but current SPINDLE runs with `--debug=yes` in default.

Start by reproducing the nested-dependency case with a Python script that imports matplotlib under SPINDLE, using the default --debug=yes behavior described in the issue. Trace how $ORIGIN is expanded for multiarray.so and verify that it resolves relative to the original dependency directory, allowing libopenblasp.so to load.

Written by the indexing model from the issue text.