rpi4: Introduce raspberry-pi."4".enable

[nobodyinperson]

Description of changes

Don't enable anything unless explicitly enabled. Otherwise e.g. the specified kernel complicates running a x86_64 vm of a rpi4 NixOS system.

In general, NixOS modules shouldn't ever just define things and always guard them e.g. by enable options.

This PR guards the unconditional configs from default.nix and cpu-revision.nix with a new flag hardware.raspberry-pi."4".enable.

Things done

• Tested the changes in your own NixOS Configuration
• Tested the changes end-to-end by using your fork of nixos-hardware and
  importing it via <nixos-hardware> or Flake input

[Mic92]

I know we do this in NixOS but for nixos-hardware users usually expect that an import is enough, so I would like to task why this option is necessary. Are overlays not needed to make the machine boot? An alternative would be also to have an enable option that defaults to true.

[nobodyinperson]

Conditional imports are not possible with the nixpkgs module system. So for example if you want to make a vm of your RPi 4 NixOS system (e.g. nix build .#nixosConfigurations.thepi.config.system.build.vm) it will fail because the nixos-hardware module hard-sets a kernel and other stuff. So either an enable flag is introduced which you can then nicely auto-disable for VMs (e.g. via options.virtualisation ? qemu, which is only true when building a vm) or you make an entirely separate nixosConfiguration only for the vm, which is uncool.

[nobodyinperson]

nixos-hardware users usually expect that an import is enough

Well all the "sub"modules for the rpi4 for example to have enable flags and users are not supposed to include them for activation. There's a reason nixpkgs does all the enable guarding. But yeah, if this is how nixos-hardware does it, then I guess an enable flag that's on by default could work to keep backwards-compatibility. Not very elegant though in my opinion.