Add iconPath and stub color optional properties to TerminalOptions and ExtensionTerminalOptions.

[rschnekenbu]

What it does

Add iconPath optional property to TerminalOptions and ExtensionTerminalOptions
Stub color optional property to TerminalOptions and ExtensionTerminalOptions
This allows creation of terminals from extension with different icons.

Fixes eclipse-theia#11504

Only commit da5f0ce is relevant in this review, the other one from lucas is only a commit missing on our fork.

Contributed on behalf of STMicroelectronics

How to test

1. Install extension terminal-creation-options-0.0.13.zip. This extension provides several actions to open a new terminal with a different icon in the title and several color options (not supported yet)
2. Trigger in the command Palette different commands:

• 'Create terminal with green Theme Icon'. a new terminal with a file icon shall open.
• 'Create terminal with red URI Icon'. A terminal with default terminal icon shall open as the URIs iconPath is not yet supported.
• 'Create new terminal' should create a terminal with standard terminal icon.

Known limitations

1. Color is not supported but stubbed, so the extension is still supported. The support is strange in vscode, as having a specific color changes also the icon to a kind of cube (at least when I am testing). The main technical reason is that underlying representation Title, coming from phosphorjs library, does not directly support styling. The phosphorjs library is deprecated now, so this may be hard to have a proper fix.
2. Only ThemeIcon is supported currently in iconPath. URI(s) based icons are not supported, but still do not fail. Same reason for the color management applies here, the limitation comes from Title only accepting iconClass string. I have seen some similar work on webview title, but this includes some dependencies to classes in plugin-ext package (PluginSharedStyle, and some other elements). In Terminal-Widget-impl, we are in terminal package, which can not depend on plugin-ext as it would introduce circular dependencies. So there maybe some other way to implement, but with either some code duplication or a larger refactoring required. This will be part of a following issue.

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

[sgraband]

Thank you @rschnekenbu! Looks good and works great!

Should we already create a follow up/discussion for the larger refactoring? Or will you open this when the PR is merged? Anyway, i see no reason to not open the real PR.

[rschnekenbu]

Thanks for this fast review, @sgraband! I opened a new PR on theia side: eclipse-theia#12060. I will open a new issue that finish the implementation once the theia PR is accepted.