refactor(treeview): mr items can be now disposed

This MR is preparation for implementing #266 (closed). It changes the way we render the TreeView. This MR doesn't change any observable behaviour of the extension.

Right now, all the items in the tree view were directly extending vscode.TreeView class. In other words, we used only the "view" components. And once we created these view components, we forgot all about them.

This worked because none of the items needed to reference any disposable resources. Disposables is a pattern used heavily in VS Code. VS Code lends the extension some resource (e.g. registered listener) and expects the extension to call .dispose() on that resource when it doesn't use it anymore. Not calling .dispose() would result in a memory leak.

#266 (closed) introduces comments and when the user clicks on the MR item to show all changed files

we will obtain a CommentController which is Disposable.

This is very rough and a bit oudated POC implementation using the CommentController.

This MR introduced a cascade of dispose() calls that starts when we call DataProvider.getChildren() (every time we refresh the Tree View).

How DataProvider works

DataProvider interface has got two important methods:

• getChildren(element?: T): ProviderResult<T[]>
• getTreeItem(element: T): TreeItem | Thenable<TreeItem>

Until now, we ignored the getTreeItem method and when we called getChildren() we directly returned the view components (vscode.TreeItem).

But the interface is meant to work differently. The DataProvider can work with elements of any type and it then renders those elements into view components by using the getTreeItem() method.

Before this MR

graph LR;
A["getChildren() produces TreeItems"] --> B["getTreeItem(element) always directly returns element"]

After this MR

graph LR;
A["getChildren() produces either TreeItem or ItemModel"] --> B["getTreeItem(element) either returns directly or calls element.getTreeItem()"]

This MR converts several TreeItem implementations into an ItemModel. To get the TreeItem "view" components, we now have to call ItemModel.getTreeItem().

The Tree View Hierarchy

Being aware of the TreeView hierarchy will help with reviewing the code and mainly the integration tests. There is a difference between single-root and multi-root workspace. The following pictures explain the difference:

single-root	mutli-root

Related to #266 (closed)