Progress extension

[olexii4]

As a continuation of the PR, with the preservation of the authorship of an origin commit.

Just tried it with 'git clone' - video

[JPinkney]

Awesome! I tested it out and it seems like the only thing that isn't working is when you focus something else the progress monitor still stays open.

[olexii4]

@JPinkney Several classes were added accidentally from your different commit. I have removed all that was unnecessary. Please, have a look.

[JPinkney]

@olexii4 It looks like the progress monitor flickers if the progress reports are coming in really fast (Tested using Che), other then that everything is working as expected.

[olexii4]

@JPinkney I have updated it (fix the progress monitor flickers).

[olexii4]

@akosyakov @AlexTugarev Could you review this PR?

[olexii4]

Just tried it with 'git clone' - video

[AlexTugarev]

'Looking into this today.
@olexii4, please take care of commit signing.

[olexii4]

@JPinkney Please, add your "Signed-off-by footer"

[westbury]

Thank you for your help in improving progress reporting in Theia. This is certainly something we need.

I was wondering how this relates to the existing support for progress reporting in the message package (showProgress and reportProgress in MessageClient and NotificationsMessageClient. That has a basic implementation (MessageClient) in the core package that simply reports to the console. The drop-down notifications are implemented in the message package. I believe this is the structure we should maintain because this means packages making notifications or progress reports need only depend on the core package. Extenders can then chose to use the message package or brand with their own MessageClient bindings.

I do not see any reason not to stick with the existing API. I can see there may be advantages in combining showProgress and reportProgress into your single addOrUpdateContribution function. However I would do that by ensuring calls to reportProgress imply showProgress not previously called.

This PR is regressing on functionality by not including a 'cancel' button in the progress, as that can be added to the current drop-down progress. However as existing progress reporters would not automatically switch to your progress dialog, that is ok.

My main concern is that we would now have two progress reporting systems, with some packages hooked up to one and some packages hooked up to another. Extenders currently will typically rebind MessageClient and delegate showMessage to one MessageClient implementation while delegating showProgress and reportProgress to another MessageClient implementation, and I am concerned this will become more confused.