sys-apps/systemd: Fix unit installation

[krnowak]

The systemd.eclass was not finding the systemd pkg-config file to
figure out the system unit directory, so it was falling back to a
hardcoded default (/lib/systemd/system). In one case (when
overriding the default.target symlink), we tried to fix that by
specifying the PKG_CONFIG_LIBDIR environment variable, but that
still did not help.

Using functions from systemd.eclass in a systemd ebuild is working
only by chance here. This eclass is usually meant for ebuilds that
depend on systemd and rely on systemd being already installed in the
root filesystem.

The functions in systemd.eclass that need to figure out some values
from systemd's pkg-config file (like system unit directory) assume
that systemd is already installed in the root filesystem, which is not
the case when we actually are building and installing systemd.

To add an insult to the injury, systemd.eclass is not using
pkg-config directly, but rather a shell script that wraps pkg-config
(for example /usr/bin/x86_64-cros-linux-gnu-pkg-config). The script
clobbers the environment variables like PKG_CONFIG_PATH or
PKG_CONFIG_LIBDIR, which is why overriding them did not work when
fixing up the default.target symlink. Thus systemd.eclass was
actually falling back to a hardcoded default value. The only way to
control the script is through either SYSROOT or ROOT environment
variables. So do so.

This fixes merging the installed files into root file system using a
newer version of portage. The failure was that systemd build system
installs the default.target symlink in /usr/lib/systemd/system
pointing to graphical.target, while we later try to override it to
point it to multi-user.target. But instead of overriding a symlink,
we installed a new symlink in /lib/systemd/system. Both /lib and
/usr/lib are separate directories in the temporary installation
directory, but in root filesystem, both are symlinks pointing to the
same directory. Which means that we ended up with two different
symlinks in temporary installation directory, and the new portage
version could not decide which one to use during the merge into the
root filesystem. I'm not sure what old portage version did here,
likely worked by chance too.

Test build: http://localhost:9091/job/os/job/manifest/1918/

[krnowak]

amd64 build completed successfully, and arm64 got some unrelated failure during image matrix build:

2021-01-29T22:53:45Z cork: Detecting versions in remote repo
ssh: Could not resolve hostname github.com: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
2021-01-29T22:54:05Z cork: Reading from remote repo failed: 'git clone dev-flatcar-master-1918' failed: "exit status 128"

[pothos]

I restarted the arm64 build