shared/install: try harder to find enablement symlinks when disabling a unit

shared/install: try harder to find enablement symlinks when disabling a unit

It might be needed to follow symlinks more deeply when we're looking for
enablement symlinks pointing to the removed service.

Let's consider the case where service 'old' is being renamed 'new' (will happen
most likely during package upgrade). Before the service is going to be renamed,
there's the following enablement symlink:

 /etc/systemd/system/multi-user.target.wants/old.service -> /usr/lib/systemd/system/old.service

In order to rename 'old' into 'new' and transparently restart the service, the
old name is still provided as a 'static' alias for the new service. This should
also help keeping backward compatibilities since the old name might still be
embedded in unit files, scripts, generators and such.

Hence after the package is upgraded, the following symlinks including the
enablement symlink are present:

 /usr/lib/systemd/system/old.service -> new.service
 /etc/systemd/system/multi-user.target.wants/old.service -> /usr/lib/systemd/system/old.service

If later the user decides to disable the service, we should figure out that the
enablement symlink (which still has the old name) is actually referring to 'new'
(indirectly) even if it points to the alias.