Support Variant of `modify_` to Prompt for Overwrite

Is your feature request related to a problem? Please describe.

I use multiple VS Code derivatives (mostly Microsoft VS Code and Kiro) between my personal and work setup. These editors are very similar and I wish to centralize my configuration to a single source of truth in chezmoi and allow for untracked machine specific variants.

This is complicated by the fact that these applications update settings.json without me directly editing it from the chezmoi source, which will cause drift between the source and destination. My current use of modify_ scripts introduces the risk that chezmoi apply wipes the drift that I would want to capture in my chezmoi source.

Describe the solution you'd like

Add a file source state attribute derive_ which is similar to modify_ but with the following distinctions:

• Prompt the user when an destination file overwrite is detected
• No standard input

I believe my proposed attribute can serve two general purpose goals:

• Create certain dotfiles where there is an odd confluence of circumstances (e.g. the application does not support multiple configuration files and the application directly edits the file)
• The user wants to maintain the configuration in one format but the application only supports another (e.g. the user uses YAML or Jsonnet building blocks to separate logical concerns but the application only supports a single JSON)

Describe alternatives you've considered

My dotfiles already have approaches to handling untracked, machine specific configs.

I have read the documentation for Manage machine-to-machine differences and I use those techniques where possible. However, there are certain items (such as work specific git configurations) where I do not want to deal with the hassle of making sure I do not inadvertently leak internal company data.

When the Configuration Tool Supports Include

This is the easiest case for me to handle. I simply include an "include local" entry in the chezmoi tracked configuration file.

For example, I have the file private_dot_config/git/create_empty_config.local and my private_dot_config/git/config.tmpl has the snippet

[include]
    path=config.local

That allows me to edit ~/.config/git/include.local which remains outside of chezmoi but is still ultimately picked up by git.

When the Configuration Tool Does Not Support Include

Admittedly, the following pattern seems more like a hack.

Git only allows for one user-global ignore file. My private_dot_config/git includes the following three files:

.ignore.dist.tmpl
create_empty_ignore.local
modify_ignore.sh

modify_ignore.sh combines the contents of $CHEZMOI_SOURCE_DIR/private_dot_config/git/.ignore.dist.tmpl and ~/.config/git/ignore.local. The problem with this approach is that any direct modifications to ~/.config/git/ignore will be lost by the next chezmoi apply. That risk is acceptable to me because the only way the derived ignore file would be updated outside of chezoi would be if I physically opened it with my text editor and modified the contents (which I know not to do because these are my dotfiles and I put in a comment saying "DO NOT MODIFY THIS FILE DIRECTLY" as a reminder)

VS Code Related Solutions

VS Code has a feature request issue open to support sourcing additional configuration files https://github.com/microsoft/vscode/issues/15909. However, this has been open for over a decade so I don't have confidence it will be addressed anytime soon.

There are a few VS Code extensions that try to fill the gap. However, I already use chezmoi, so I would rather drive my configuration from just one place.

VS Code's Profiles, replace the baseline settings entirely, not extend them with customization as I hoped.

Additional context

The add-on VorpalBlade/chezmoi_modify_manager does not quite fit my use case. The VS Code settings.json is all configuration, not a mixture of configuration plus state.

I agree with the semantic intent of modify_ as discussed in #1296 and #2244. My use case just touches on a different set of concerns, hence proposing derive_.