Configuring wrappers to use writable copies of paths

[thou-vow]

The idea is for the wrapper to instead of directly using paths pointing to store, copy these paths to a chosen location as writable and use that (of course always check if the aimed file or directory exists in the chosen location before doing that operation). This makes the process of fixing small bits of configuration much quicker, avoiding Nix evaluation/building until everything's done.
I wonder if that's possible without a new implementation of makeWrapper interface.

[BirdeeHub]

So, you can put any path there. Including outside of the store.

For example, in the nvim module by default it looks at the path returned by the lua expression vim.fn.stdpath('config') at runtime until you set that to be somewhere else.

You can do this in any of the built in makeWrapper options too (obviously not with lua, but if you change the escaping function you can put bash there, which with the default wrapperImplementation = "nix" will run at runtime!).

So, if that path is there at runtime, it will work at runtime, and you will be able to edit it.

We also have wlib.mkOutOfStoreSymlink, just in case putting the absolute path as a string would have worked but the option itself needs a derivation.

However, if it was outside of the store, its not going to copy it there for you.

In order to copy it there, we only have THAT derivation to work with.

The options we can do from here would be:

• Make the wrapper script copy it at runtime if it doesnt exist. The noctalia-shell wrapper module does this actually. But it would have to run every startup. We try to avoid this if the program doesnt NEED to write to it.

• Export a service via one of the paths for that which copies it there somehow on some sort of trigger, then in nixos or home manager install it via systemd.packages option, and then enable the service. This will be much easier when we have dedicated options for generating those service files, which we do not yet, but can already be done with constructFiles or buildCommand options. And as far as installing and enabling the service exported in that manner, WIP: feat(core.install): integration module options #405 <- this PR or something like it will help automate that. This would be cleaner than checking every startup, but is also much harder to do until we have proper service options.

• Usually, it is nice to simply change the path to a regular "/home/user/wherever" kind of path when editing and build that on its own as just a package, which is much faster because it is just that package, and then it will result in an unlocked config so you can edit further without doing it again, and mess with it until you are happy with its behavior, and then change the path back and rebuild with it as part of your configuration using a pure path when done.
  Most of the wrapper modules allow you to do this in basically any option they offer, because they usually use wlib.types.stringable instead of lib.types.path or lib.types.package, some of them have a build time config validity check that may need disabling but most do not. If you experience issues with that at any point, let us know in an issue, we can add some sort of option to disable the check or whatever but you usually can still override those yourself in the meantime, or use mkOutOfStoreSymlink