feat: commit stacking

[ldelossa]

Description

This feature introduces a useful way to checkout commits when performing code review or browsing large repository, called 'commit stacking'.

The idea is to add a stack of Commit.
The user can push and pop commits to this stack as they jump around the code.
When the user pops the entire stack Gitlens restores the repository to the ref that was checked out before the first push of a commit.

To accomplish this three new commands were added:

'switchToCommitStacked':
accessible from the right click context menu in the commit's view. this pushes the selected commit onto the stack and checks the repository out to it.

'switchToCommitPop' -
accessible from the navigation menu in the commits view. this pops the top commit from the stack and checks out the new head of the stack.

'commitStackEmpty' -
accessible from the command pallete.
this is a shortcut to immediately clear the stack and check out the original ref before the first commit was pushed to the stack.

Additionally, a status bar item is created when the stack has items on it.
This format is commit stack: ${curNode.ref.name} ${this.commitStack.length} where curNode is a ViewRefNode.

The reason this feature is rather useful is because LSP tools do not work when viewing diffs spawned from commits. Instead, VSCode opens read only editors where you can no longer navigate code with the LSP. Even if the diff editor is not read only, some LSP's simply won't work in this view.

By supporting commit stacking a user can quickly jump to a commit, navigate it with their LSP tools, and hop right back to where they were. Additionally, the user can make arbitrary jumps between commits without having to keep a list of which commits they jumped between.

Demo
https://github.com/gitkraken/vscode-gitlens/assets/5642902/7ff7339b-7f4d-44a6-b952-470b90d57099

Issue created: #2868

Checklist

• I have followed the guidelines in the Contributing document
• My changes follow the coding style of this project
• My changes build without any errors or warnings
• My changes have been formatted and linted
• My changes include any required corresponding changes to the documentation (including CHANGELOG.md and README.md)
• My changes have been rebased and squashed to the minimal number (typically 1) of relevant commits
• My changes have a descriptive commit message with a short title, including a Fixes $XXX - or Closes #XXX - prefix to auto-close the issue that your PR addresses

[eamodio]

Thank you for your efforts here! Can you help me understand the workflow that this enables? I can understand the desire to checkout to a specific commit for LSP to work properly, but why the stacking? What is the workflow to toggle back and forth?

[ldelossa]

Thanks a lot for your attention.

So the workflow I was trying to solve here was this scenario.

1. Checkout a PR with multiple commits you want to explore
2. Push a commit to the stack you want to explore in detail
3. Realize that while your exploring this the code you need to look deeper into was introduced in yet another older commit (via gitblame or just a link to a previous commit provided in the current commit's message).
4. Add this older commit to the stack so you can explore the code with LSP
5. Pop the older commit from the stack, so you can just continue where you were.

The reason this 'memory' of the stack is useful is become

1. Gitlens (and any other tool which lists commits) will only show the current commit and older when checking out a commit, making it difficult to get back to where you just were
2. The usual way to do this is just to keep notes on the side of your editor where you manually copy and paste the commit list you care about, and I think this could actually be replaced by the 'commit stack'

If this feature is supported, I'd also like to nicely support a way to automatically add multiple commits to the stack to support this workflow

1. Checkout a PR with (gh pr checkout)
2. Place commits introduced in PR on the stack
3. Navigate each commit by popping the stack so you can inspect each commit with LSP tools enabled and perform per-commit review.

Those are my end goals with this. Very happy to get opinions and understand if this is a bit too contrived for the Gitlens project, I can always maintain fork :). But if you see usefulness in this idea i'm welcome to massaging it to something you agree with.