Fix restore --staged for certain vfs ops

[tyrielv]

When using virtualfilesystem, Running git restore --staged after git cherry-pick -n or git reset --soft would result in an incorrect state - the modified files would still have their modified contents, but git would no longer recognize them as being modified; and the added files would be deleted from disk instead of just unstaged.

See microsoft/VFSForGit#1855 for more details.

This commit fixes these issues with two changes:

Add a new flag to the index state structure, vfs_check_added_entries_for_clear_skip_worktree. This flag is set during cherry-pick -n before calculating the new index state, and causes newly added entries to have their SKIP_WORKTREE bit cleared. This ensures that newly added files are added to both the index and the worktree in the next step. Otherwise, sparse-checkout would prevent them from being added to the worktree.

Set the existing flag updated_skipworktree on the index when running a checkout index (aka restore --staged) operation. These operations already will clear SKIP_WORKTREE bits for modified files, but without this flag set the virtualfilesystem hook notification does not indicate that they changed, causing the VFS to not update its state correctly.

Thanks for taking the time to contribute to Git!

This fork contains changes specific to monorepo scenarios. If you are an
external contributor, then please detail your reason for submitting to
this fork:

• This is an early version of work already under review upstream.
• This change only applies to interactions with Azure DevOps and the
  GVFS Protocol.
• This change only applies to the virtualization hook and VFS for Git.