We have to break the dependency chain mentioned in
b06cb35.
(systemd -> cryptsetup -> lvm2 -> udev=systemd)

We do this by updating the lvm2 derivation to build without udev, so we
can give systemd a (lib)cryptsetup it can link against. We still need to
check whether this is enough, or if lvm needs to be bootstraped by a
udev/systemd which does not yet contain cryptsetup support - hopefully
not.

While working on the lvm2 derivation, the following cleanups where done
in the lvm2 derivation:
 - set installFlags directly, instead of doing it inside a script in
   preInstall
 - use installTargets again ("install", plus
   "install_systemd_{generators,units,configuration}" when udev is not
   null)
 - The call to the blkid binary in lvm2's 13-dm-disk.rules file
   disappeared (so we don't need to patch in blkid anymore).
   lvm seems to rely on udev's internal blkid functionality.
 - Call /run/current-system/systemd/bin/udevadm instead
   of ${systemd}/bin/udevadm in the lvm activation generator.
   This is not necessary to break the dependency cycle (as we don't use
   that file when building wihtout udev), but a good idea anyways -
   We want to trigger the udevadm of the current system, not the one
   that lvm was built with.
 - Remove the unused purity.patch

Co-Authored-By: Arian van Putten <aeroboy94@gmail.com>

…yptsetup-generator.c)

This package previously did override the systemd package, and instructed
ninja, systemd's previous build system, to only build the
cryptsetup-specific systemd generators (plus some rpath massaging, as we
didn't use ninja install).

Afterwards, users were expected to add this package to their
`systemd.generator-packages` NixOS module options, so systemd will use
these generators.

As the previous commit added cryptsetup support directly to the systemd
package (and pkgs.systemd now already ships the cryptsetup generators),
we don't need another package shipping the same generators.

So we remove the custom derivation. It might be possible to alias the
attribute to `systemd`, as adding systemd's generators to the list of
used generators should be a no-op, but it's cleaner to prompt users to
update their configuration.

Instead, prompt user to add it to systemd.system-generators, which is a
cleaner way, and we don't need to rebuild the world by changing systemd
globally.

Initially introduced in c0fd887.

We might want to do this conditionally on whether lvm is enabled (or add
the lvm system-generators unconditionally, too)