worktree reset

[Byron]

Based on #1008 .

Implement a proper worktree reset, eventually leading to a high-level reset similar to how git supports it.

Tasks

• gix status draft with index-worktree support and progress support, and pathspec support
• add submodule support to index-as-worktree in gix-status
• diff index with index to learn what we would want to do in the worktree
• reset() that checks if it's allowed to perform a worktree modification is allowed, or if an entry should be skipped. That way we can postpone safety checks like --hard
• figure out how this relates to the current checkout() method as technically that's a reset --hard with optional overwrite check. Could it be rolled into one, with pathspec support added?

Postponed

What follows is important for resets, but won't be needed for cargo worktree resets.

• a way to obtain git status only for a selection of entries that we would want to touch
• a way to obtain untracked files to learn if changes can be made

Research

• How to integrate submodules - probably easy to answer once gix status can deal a little better with submodules. Even though in this case a lot of submodule-related information is needed for a complete reset, probably only doable by a higher-level caller which orchestrates it.
• How to deal with various modes like merge and keep? How to control refresh? Maybe partial (only the files we touch), and full, to also update the files we don't touch as part of status? Maybe it's part of status if that is run before.
• Worthwhile to make explicit the difference between git reset and git checkout in terms of HEAD modifications. With the former changing HEADs referent, and the latter changing HEAD itself.

[Skgland]

It doesn't look like closing this was intendet.

[Byron]

No, it was not 😅. I published something while on this branch, instead of main, and now the tag is setting this history in stone and I had to bring it into main. Oh well…probably time to call it a night.