zfsbootmenu/install-helpers.sh: preserve relative symlinks

[ahesford]

When installing symlinks into their initramfs images, both dracut and mkinitcpio attempt to canonicalize symlink targets, copying the resolved target into place and making a new symlink that points to there. This means that, even when building a local image, symlinks like poweroff and zbm will point copies of scripts in /usr/lib/zfsbootmenu/bin rather than the versions already installed into /usr/bin. For container builds or those built from custom installations that override $zfsbootmenu_module_root, the target paths get even weirder in the initramfs image. It's also problematic, because people doing testing may attempt to modify things like /usr/bin/zfsbootmenu in situ and be surprised when they run zbm and get a different copy of the script than the one they modified.

I've made a simple helper that tries to do the right thing with symlink as we use them. When installing a file, if it is a symlink and resides in $zfsbootmenu_module_root, then the relative link will be replicated in the initramfs image. This seems to work as intended for the handful of symlinks that we install.

In the original implementation, I required that the symlink point to a file in the same location and did not attempt to install the target, instead relying on a zbm_install_file call for the actual target to add the file separately. In the fixup commit, I instead attempt to install the target in a location where the symlink will find it. I'm open to suggestions on how to improve this target installation, and am also willing to just drop the fixup commit.

[ahesford]

This may or may not be related to #616; I can't reproduce that issue when generating dracut or mkinitcpio images on my host when standing up testbeds.