`/` does not need to be mounted if `roothash` is specified in the kernel command line

[msanft]

Describe the bug

The initrd builder of NixOS makes assertions on fileSystems."/" being specified when building an initrd (i.e. its fstab, from which systemd-fstab-generator creates the mount units). When using a dm-verity system, with the roothash option specified in the kernel command line, systemd-veritysetup-generator will already have taken care of creating the mount unit, causing the subsequent try to create the unit by systemd-fstab-generator to fail. This makes it hard to build immutable, image-based appliances where one would want a dm-verity protected rootfs created through veritysetup without overrides to the module.

Steps To Reproduce

Steps to reproduce the behavior:

1. Build an image with a verity partition and the roothash option specified in the kernel command line.
2. Boot the image.
3. See the error message in stage 1:

   
   Welcome to NixOS 24.05 (Uakari) (Initrd)!

[ 0.406772] systemd-fstab-generator[69]: Failed to create unit file '/run/systemd/generator/sysroot.mount', as it already exists. Duplicate entry in '/nix/store/2y5fanvgc23zfqpq0pjcm0v8hmfv452s-initrd-fstab'? [ 0.409288] (sd-e[67]: /nix/store/vfmf8qh892jfl107hih0yfnic00byjgj-systemd-254.6/lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1.

### Expected behavior
Assertion should not hit or be able to be suppressed.

### Additional context
I'm not entirely sure what the best fix for this would be. Options I have thought about include:
- Adding a suppressor option for the assertion, which is probably the least involved fix, but also has the worst UI.
- Adding a `boot.initrd.systemd.veritysetup` (or similar) option, that specifies the necessary command line options and additional units for using veritysetup.
- Adding a `withVeritysetup` option to the `systemd` package, similar as it is done with [`withCryptsetup`](https://github.com/NixOS/nixpkgs/blob/a5ae45e45af0a697a219eb4da2827fe3cf4e9374/pkgs/os-specific/linux/systemd/default.nix#L98). NixOS modules could then check whether the attribute is enabled and include services and disable assertions based on that.

### Notify maintainers

<!--
Please @ people who are in the `meta.maintainers` list of the offending package or module.
If in doubt, check `git blame` for whoever last touched something.
-->

Adding @ElvishJerricco, as he seems to be the most active maintainer of stage1 / systemd-initrd.

### Metadata
Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.

```console
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.7.2, NixOS, 24.05 (Uakari), 24.05.20240127.160b762`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.1`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

---

Add a :+1: reaction to issues you find important.

[ElvishJerricco]

We need better handling of root= stuff anyway, as evidenced by https://github.com/NixOS/nixpkgs/pull/282022. Systemd supports a variety of ways of specifying the root file system, and we need to reflect that as best as possible in nixos. So I think this issue is part of a broader concept we need to flesh out.