ZFS improvements

This PR does the following:

* Uses the upstream systemd services by default (including the one for zed - the ZFS Event Daemon)
* Reimplements the ZFS pool import service so that:
  * We do not fail if there are no ZFS pools to import
  * We not rely on `/etc/zfs/zpool.cache`, which eliminates some issues
  * Instead, the ZFS pools to import have to be specified in `configuration.nix`
  * To avoid issues and make configuration simpler, NixOS will automatically infer the necessary ZFS pools to import for ZFS filesystems which are defined in `fileSystems.*`
  * For ZFS pools which are not mentioned in `fileSystems.*`, the user will have to add them to `boot.zfs.extraPools` if they want them to be automatically imported on every boot
  * Please note that the way in which this PR is now importing ZFS pools is more or less the direction in which upstream ZFS seems to be moving towards
* Added option to disable force import (i.e. `--force / -f`) of ZFS pools. Currently, we still force-import by default to maintain backwards compatibility with NixOS systems that don't have the host ID recorded in their ZFS pool labels, but once most people upgrade to this PR we should disable force-importing by default
* Reimplement SPL's host ID configuration so that:
  * The SPL now correctly picks up the host ID defined in `configuration.nix` (this wasn't happening before due to a bug in the SPL)
  * The host ID is now configured system-wide by writing it to `/etc/hostid`, which makes the ZFS userspace tools agree with the kernel as to what the host ID is. It also makes glibc (and therefore, other unrelated applications) pick up the host ID defined in `configuration.nix`
  * Renamed `boot.spl.hostid` to `networking.hostId`, to make it clear that the host ID is a system-wide config option and not tied to the SPL. I've put it under `networking` because it closely resembles `networking.hostName` in terms of purpose
  * Only allow ZFS to be enabled if `networking.hostId` is set. Otherwise, ZFS pools will not record the host ID in the vdev labels and it will be impossible to open or import a ZFS pool without passing the `--force / -f` parameter
* Make `nixos-generate-config` generate a random 32-bit host ID by default (when installing NixOS). This makes the host ID more reliable than falling back to the default glibc behavior of generating a host ID based on the IP address, which can change quite often and conflict with other machines in the same network in some cases. It also makes using ZFS easier by not requiring the user to worry about manually generating a host ID themselves and adding it to `configuration.nix`

The commit messages contain a bit more details regarding the issues above.
Using /dev/urandom is fine by me :) I will fix that, thanks!

Regarding MAC address, what if you generate a host ID using the MAC of machine 1's network adapter, then move that network adapter to machine 2 (because you are doing maintenance and reinstalling machine 2) and then generate a new host ID in machine 2? They would end up with the same host ID?

To me, using /dev/(u)random seems less error-prone, and by design it has to be seeded with as much unique information as possible. It is true that it doesn't guarantee uniqueness due to random collisions, but I'm not sure there is anything that is truly reliably unique, especially with such a small 32-bit integer space...

According to my calculations (using birthday paradox formulas), if you generate 32-bit host IDs randomly, then if you have 10 machines, it's only a 0.000001% chance that 2 of those machines will end up with the same host ID. If you have 100 machines there is only a 0.0001% chance.

At least with random host ID generation we can calculate the collision probability exactly, while if it's not truly random, then it's much harder... I think, more likely the probability of collision will be higher due to unforeseen events, depending on how you generate it.

Consider, for example, the above case of moving network adapters from one machine to another, or moving a machine from one network to another, or using exactly the same simple hardware (such as a Raspberry Pi) in 2 different machines, ...