Spack used to have a flag spack buildcache create --rel which was removed in v0.20.0.

This PR removes the install part of that feature, meaning that binary cache entries created with --rel will only work if they are installed to a store with identical projections. A warning is issued if users install an old tarball that was created with --rel.

The function of --rel was to take absolute rpaths like

$ readelf -d /path/to/store/linux-aarch64/gcc-10.3.0/pkg-1.2.3-abcdef/bin/example
... Library rpath: [/path/to/store/linux-aarch64/gcc-10.3.0/dep-1.2.3-abcdef/lib/libdep.so]

and make them relative to /path/to/store using $ORIGIN:

$ORIGIN/../../../dep-1.2.3-abcdef/lib/libdep.so

so that under identical projections, there is no need to patch rpaths. In practice however:

1. projections change (and we are going to change it in etc/defaults/config.yaml), so upon install $ORIGIN/../../dep-1.2.3-abcdef/lib/libdep.so had to be expanded to an absolute path, and nothing was gained.
2. use of $ORIGIN shrinks the rpath, meaning users had to run patchelf to create a whole new dynamic section, which sometimes breaks binaries if they were stripped.
3. we continue to scan the entire binary for non-rpath strings to relocate, so there's no performance gain either
4. there are bugs when dependencies are in upstreams during build or upon install.

In other words, it's unlikely that users benefited from and used --rel, and it's been removed long enough to stop supporting the install side of it.

So, this PR removes the code that did the dance of expanding $ORIGIN rpaths to absolute paths, and simply leaves these rpaths relative.