Rejection should prefer the ImportMany site over the Export site

[AArnott]

When vs-mef encounters this graph error:

Microsoft.VisualStudio.Text.Editor.Implementation.WpfTextEditorFactoryService.WpfTextViewCreationListeners: is not assignable from exported MEF value Microsoft.PythonTools.Django.Intellisense.TemplateTextViewConnectionListener.
   part definition Microsoft.VisualStudio.Text.Editor.Implementation.WpfTextEditorFactoryService 

EXPECTED

The TemplateTextViewConnectionListener MEF part should be rejected from the graph, as that is where the fault lies.

The graph analysis justification for this may be any or all of the following reasons:

1. WpfTextEditorFactoryService has the [ImportMany] attribute, suggesting it's in a more vulnerable position to bad actors, and should not be penalized when one exists.
2. The import site's type identity strings matches the import element type, which is a very strong indicator that it is correct.

ACTUAL

vs-mef throws out the WpfTextEditorFactoryService instead.

[ZoeyR]

This would have to be a backwards incompatible change. TemplateTextViewConnectionListener could export itself as multiple types. If it is rejected from the graph then it will break components that imported it as one of the other types it was exported as.