perl issue - rpath vs ld_library_path

I've been trying to create a non-container environment on NCI (to help me/the devs to debug a tau build issue in our container). So I used the aws setup. After some work, I got problems when spack compiler perl:
```
loadable library and perl binaries are mismatched (got handshake key 0xf380080, needed 0xcd00080)
```
(the handshake keys might have been different).

The reason is that spack uses rpath, and the rpath added on nci (`/half-root/lib...` something or other) contains some libs that are required, but this directory also contains a library for perl. So the newly compiled perl has an rpath to a directory that contains the old perl lib, which is not compatible.

The suggested solution from https://github.com/spack/spack/issues/40848 was:
```
spack config add config:shared_linking:type:runpath`
```
This indicates that LD_LIBRARY_PATH should take precedence over rpath. This solved at least this issue for me.

I am wondering (and hence opening a ticket, given that my approach of using aws scripts on nci is rather unusual ;) ) if this should either be documented (as useful info for other sites), or if we should consider using this in general? I can't judge the impact (and am equally happy to just get this ticket closed with 'too esoteric' as reason :) )

Review the AWS setup and Spack configuration around compiler environments, then verify how setting shared_linking:type:runpath affects the Perl library mismatch. Done means either documenting this NCI workaround for similar sites or recording a clear decision not to adopt it generally, including its known impact.

Written by the indexing model from the issue text.