view_copy: relocate symlinks

[haampie]

fixes #33606
fixes #19550

Previously spack:view:default:link_type:copy did not handle symlinks:
it changed symlinks into redundant file copies, errored on dangling
links, and failed at symlinked directories.

With this commit it actually creates symlinks, and relocates them if
necessary. However, it's far from perfect (doesn't properly check if a
symlink points into a prefix dir in multiple ways: relative symlinks
aren't checked whether they escape the prefix, and absolute symlinks are
not checked in realpath sense). But held to the standard of
Spack's current relocation logic nobody can complain...

Supersedes #31958

[haampie]

@becker33 this might need a proper refactor, since some valuable information is lost when entering view_copy. The directory visitor has much more data (relative paths, whether src is a symlinked file or symlinked dir, ...), the view_copy just receives two abs paths, which is cumbersome.

[vsoch]

Yay! Thanks @haampie!

[becker33]

One request to update a comment, otherwise LGTM.

Oh also an entire conversation with myself about inaccurate old comments, which I'm leaving here in case it's useful for anyone, but should not hold up the PR.

[vsoch]

heyo! Just want to make sure we don't forget this one - it's blocking us from building a view of flux in our container bases PR. Thanks!

[haampie]

@becker33?

[haampie]

bump @becker33...

[haampie]

bump @becker33, a month later... can you please review or assign someone else? Thanks.

[alalazo]

@becker33 @haampie What is the status of this? Should we merge it or is it superseded by renameat2?

[alalazo]

Can we come up with unit tests and briefly describe the various cases we test there? I think that would be valuable for future refactoring. Other than that, this basically LGTM.

Review comments have been addressed