[Threading] Fix MEF importing constructors that are not free-threaded

[duncanp-lseg]

Description

According to the threading cookbook MEF importing constructors must be free-threaded i.e. be able to run entirely on their callers thread whichever thread that is
=> no thread switching
=> cannot safely call serviceProvider.GetService(...) : we might not be on the UI thread, and if not we can't switch to it.
=> cannot safely call any method on IThreadHandling.

We definitely have older components that break this rule.

In some cases it will be fairly easy to move a serviceProvider.GetService(...) caller out of the constructor.
However, if a component is requesting a service to register for notifications from VS then it will be more difficult to fix e.g. ActiveDocumentTracker (? queue work to finish initialization on idle?)

Affected types

Definitely not ok, but probably straightforward to fix

See #4856.

Definitely not ok - calls GetService: probably straightforward to fix

Addressed here -> #4861. All fixed.

Definitely not ok - tricky to fix

• ActiveDocumentTracker: calls RunOnUIThread.Run((() => ...) // tricky. Registers for events.
• ActiveSolutionTracker: tricky. Calls GetService and then registers with the service for VS events
• FileRenamesEventSource: Calls GetService and then registers with the service for VS events
• AnalysisIssueSelectionService: Calls GetService and then registers with the service for VS events
• TaggerProvider (trickier - would benefit from some refactoring first)
• ActiveSolutionBoundTracker (Might be trickier -> calls configurationProvider.GetConfiguration() and SetBoundSolutionUIContext())

One option that we discussed offline for e.g. IActiveDocumentTracker:

• add a new interface IActiveDocumentTrackerInitializer with a single Initialize method
• make the existing IActiveDocumentTracker implement the new interface
• move the "call VS and register for events" code from the constructor to the new Initialize method
• make a package MEF-import the new IActiveDocumentTrackerInitializer interface and call the Initialize method. It would need to be a package that loads early in the process, as VS events won't be handled until that package has loaded.

Possibly not ok

Addressed here -> #4856

Ok currently, but could be modified to not make extra calls in the constructor

• RuleInfoTranslator: calls xamlTranslator = xamlTranslatorFactory.Create();. This looks to be thread-safe currently. However, it would be trivial to delay the call until the translator is actually required.
• SimpleRuleHelpXamlBuilder: calls ruleHelpXamlTranslator = ruleHelpXamlTranslatorFactory.Create(); // same - looks ok, but would be easy to make the construction lazy.
• StaticXamlStorage: similar. Calls var ruleHelpXamlTranslator = ruleHelpXamlTranslatorFactory.Create(); // the rest of the setup in the constructor is already lazy.
• TelemetryManager: probably ok. Need to check the effect of the calls it makes.

Specific issues tracked by other tickets

• SonarLintSettings: creates VS ShellSettingsManager and calls it. See [Infra] Refactor SonarLintSettings to follow VS threading rules #4843.