home-environment: interactively inspect non-managed files

[dermetfan]

Some programs overwrite their config files to save changes, such as XFE (X File Explorer). Instead of writing to the link target (which is read-only) it simply removes the link and writes its config. The next home-manager switch then complains about a collision even though the file is managed.

This PR inserts an interactive inspection to the activation script. It allows the user to view and diff the file in question. If the user decides not to overwrite (the default), the activation is aborted.

For now I chose less, diff, and exa as ls with some color, but those could be made configurable.

[rycee]

I'm a bit reluctant to add interactivity into the activation script. In particular I think we must keep the option of integrating Home Manager into the users.users module of the NixOS configuration.nix. Since the NixOS activation script runs during boot it would be very unfortunate to risk blocking for user input.

I can think of a few possible solutions:

1. Keep the interactivity but only if an new enum home.file.<name?>.overwrite is set to ask (possible options would be yes, no, and ask with default being no). Any module using ask would be a potential boot blocker but at least it would limit the problem and one could warn about it in the module documentation.

2. As 1 but make overwrite a boolean. For XFE we'd set it to true. In the module document we'd then write that any configuration changes made from within XFE will be lost on the next activation.

3. Patch the package not to mess around with the configuration file. For XFE this would mean that the configuration functionality within the XFE program is disabled when installed through the XFE module.

I'm leaning towards 2 since it is more straight forward and leaves no risk of blocking. Option 2 also closely match how the gnome-terminal module works today, you can change your settings as much as you want but on the next activation they will revert back to the Home Manager ones.

[dermetfan]

I was also concerned with blocking. My first idea was that in a non-interactive shell read would simply exit so the default [N]o would be chosen. When I tested using [[ $- == *i* ]] it turned out that the activation script is run by nix-build and therefore never interactive, and that's why I needed to hack with read < /dev/tty. If we want to add this it should run in a proper interactive shell, so I agree with option 2.