[Infra] Add integration test to check that all MEF exports can be exported

[duncanp-sonar]

Description

We have component-level unit tests that check that each individual component can be exported if the unit test supplies the correct imports. However, we don't have any integration-level tests that check that all of our exported objects can actually be created at runtime i.e. when VS loads and tries to resolve all of the MEF imports at runtime.

We only tend to find these types of errors when launching VS in debug mode, and when a MEF composition does occur at runtime it can be difficult to work out the root cause of the problem as a single missing import will cause all transitive imports to fail. Also, a MEF composition failure might not occur immediately - we might need to manually exercise some features to see a failure.

It would simplify and speed up debugging and troubleshooting if we had an integration-level test that checked the set of exports/imports e.g.

• build a list of all of the SonarLint assemblies
• walk the SonarLint assemblies looking for exported types
• for each exported type, create a SingleObjectImporter and attempt a MEF composition

Notes:

1. we'd need to load all of the dependent assemblies too i.e. any framework or VS assemblies required to instantiate any of our exported types
2. we'd need to provide a dummy implementation of any VS exports such as SVsServiceProvider and perhaps some Team Explorer exports. Alternatively, we could skip checking some of our exported types.
3. we know we have some MEF exports that do extra work in the constructors (see [Threading] Fix MEF importing constructors that are not free-threaded #4512). These might cause composition failures e.g. if the constructor tries to fetch and use a VS service.

Point (1) would add a lot of complexity in locating and loading the appropriate VS/.NET framework assembly.
A lighter-weight option would be to build a list of all available exports and then, instead of trying to actually instantiate each one, look at the types required in the ImportingConstructor to check that they are all available. That would be a less stringent test, but much easier to implement and faster to execute.

Also, the fact that some of our MEF classes fetch services in the constructor causes problems with multiple classes.
There is a separate ticket to address this: #4512.