[REQUEST] Ability to choose which .gitignore to add a file to when in a subdirectory

### Describe the feature or problem you’d like to solve

It is often the case that I have non-top-level *.gitignore* files with specific rules in them, especially in repos with multiple subproject. For example, I may have a setup like this:

- */.gitignore*: Top level file, maybe has, say, general Qt ignore rules.
- */subproject1/.gitignore*: Specific to subproject1, e.g. application output files or whatever.
- */subproject2/.gitignore*: Same deal

Now, GHD allows you to right-click a file in the changes pane and provides some "Add to .gitignore" functionality in the context menu.

However, it always adds to the top level file.

So in the above scenario, for example, if I left some file like */subproject1/some-unwanted-file.txt* around, and my intent is to add it to */subproject1/.gitignore*, I can't actually do that through the GHD GUI: If I do it through the context menu, it will add "subproject1/some-unwanted-file.txt" to */.gitignore*, when what I really wanted to do was add "some-unwanted-file.txt" to */subproject1/.gitignore*.

It would be nice to have some way to specify which directory's *.gitignore* to add the file to directly from the GUI.

### Proposed solution

I can think of a few options, but I don't really know which would have the best UX:

1. Don't offer a choice, just try to pick the closest existing one:
- If the file's directory has a .gitignore, use that one.
- Otherwise keep going up the tree and looking for one that exists.
- If none exist, create a new one in the repo root.
- **Pro:** Doesn't add complexity to the context menu.
- **Pro:** Maintains current behavior when no .gitignores (or only /.gitignore) exist.
- **Con:** As is the case now, this might make the wrong choice. Providing an option (see next point) would increase UI complexity, and would only partially address this anyways.
- **TBD:** Perhaps an option could be added to settings to choose between "always add to root" (current behavior), "always add to current dir" (creating a new one if it doesn't exist), or "choose the closest and default to root" (as described above)?
2. Provide two sets of "Add to .gitignore" options in the context menu: One to add to the root .gitignore, and another to add to the .gitignore in the same directory as the file.
- If the chosen .gitignore does not exist, create it.
- **Pro:** Gives user a choice, more flexible that the above options.
- **Con:** Adds complexity to the context menu.
- **Con:** Still might not offer the desired choice, if there are other .gitignores between the file's directory and the root (imho, though, this is good enough).
- **TBD:** Context menu organization. Could be flat, or hierarchical, and hierarchy could either have "Add file" and "Add all *.ext files" at top, or "Add to /.gitignore" and "Add to dir/.gitignore" at top. I have no opinion on this.
3. Provide every option in the context menu. Have "Add" and "Add all *.ext files" each expand to a submenu containing all the parent directories of the file, up to the root. Location can be selected there.
- If the chosen .gitignore doesn't exist, create it.
- **Pro:** Provides all possible options; has the most flexibility.
- **Con:** Adds the most complexity to the context menu.
- **TBD:** Not sure what is better UX: root path at *top* of submenu, or at *bottom*.
4. Do something else that I didn't think of. 🤷‍♂️
5. Do nothing. 😢

The other unknown with all 3 of the above options is whether or not to give a choice to add all files *named* "file-to-ignore" to a parent .gitignore or not. That is, if e.g. ignoring */subproject1/filetoignore*, providing a choice between adding "/subproject1/filetoignore" to the root, "filetoignore" to the subdirectory, or "filetoignore" to the *root* (this third option differs from the current behavior). Personally, I don't think it's necessary, but it's worth mentioning -- I don't think *every* option needs to be accessible through the GUI.

Personally, option 2 above is my preference. I think it's a decent balance of flexibility and UX simplicity, and it covers pretty much all my own use cases, anyways.

No source file or test is named in the issue. Start by locating GitHub Desktop’s changes-pane context-menu action for “Add to .gitignore” and trace how it selects the repository-root file; review the proposed UX options before changing scope. Done requires an agreed directory-selection behavior, correct relative patterns, and coverage for existing and missing .gitignore files.

Written by the indexing model from the issue text.