Support indeterminate progress notifications

[planger]

What it does

• Default to progress notification type if showProgress() is used instead of overwriting it with info
• Pass progress notification type through to view to make it aware that this is a progress without having to specify a value for the progress
• Show indeterminate progress animation if notification type is progress but no numeric progress value is specified
• Use info icon by default in view for progress notifications (this was implicitly done before too because we overwrote the notification type with info if the client didn't specify one
• Add sample menu contributions to document and test progress notifications with determinate and indeterminate progress

Fixes #10944

How to test

Use the added sample commands "Sample Command With Indeterminate Progress Message" and "Sample Command With Progress Message". See also their handler implementation in sample-menu-contribution.ts, in particular how one reports no progress (indeterminate) and the other one does.

With progress reporting:

Without progress reporting:

Other Observations

• Theoretically you can specify a message type with messageService.showProgress({ type: MessageType.Error, ...}) even though the argument type ProgressMessage dictates the optional type parameter to be of type MessageType.Progress. If clients still set another type, such as MessageType.Error this would affect the icon being shown in the notification. This PR doesn't change that behavior, but we only show an indeterminate progress, if the message type is MessageType.Progress.
• Reporting a progress { done: 0, total: 100 } is equal to specifying no progress, which is after this PR indeterminate. This might be surprising, but I felt it is fine as no progress bar would otherwise be visible anyway. This is because of the way how a progress update is handled in NotificationManager#toPlainProgress().
• Clients can't switch for existing notifications from a determinate progress to an indeterminate progress, because NotificationManager#reportProgress(...) falls back to previous progress message, if the new one is undefined. I guess this behavior is fine, because otherwise clients would be forced to always provide a work in their update, even if they just want to set a new message.

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[msujew]

LGTM!

• Normal progress notifications with progress are displayed as usual
• Progress notifications without a progress property are displayed as in VSCode
• Normal notifications continue to work as expected

[msujew]

Nitpick:

Suggested change

	const type = message.type ? message.type : MessageType.Progress;
	const type = message.type ?? MessageType.Progress;

[planger]

Thanks for the fast feedback and your suggestion!
I applied this change and also used the ?? operator in notification-component.tsx with the newly force-pushed commit 9f7c090.