Perf: review slow running early workbench contributions

[bpasero]

Refs: #156864

I instrumented slow running code that executes via registerWorkbenchContribution at an early stage before editors restore. In devtools you will see a warning in case the contribution needs more than 5ms being instantiated:

The time we spend here is time we take away from the user before the editor contents appear, thus we block the critical startup path.

I did some experiments from a custom build that includes this change on platforms and found some contributions that constantly appeared with above 5ms construction times.

Task

• use devtools profiling to see if there is a low hanging fruit to improve performance
• review if the contribution could run at a later phase, e.g. LifecyclePhase.Restored or even LifecyclePhase.Eventually

List

• LocalTerminalBackendContribution @Tyriar
• ExtensionsContribution @sandy081
• PreferencesActionsContribution @rzhao271
• UserDataSyncWorkbenchContribution @sandy081
• ExtensionsViewletViewsContribution @sandy081
• InteractiveDocumentContribution @rebornix
• RemoteEmptyWorkbenchContribution @aeschli

[bpasero]

Thanks!

[rzhao271]

Due to #159875, I'd like to split PreferencesActionsContribution into smaller sets of contributions, because some parts, such as the button that brings the user from the Settings UI to the Current Profile Settings JSON, can probably be contributed later than others.