Issue a warning if the assemblies found in the current assembly list do not match the target framework of the decompiled assembly

[siegfriedpammer]

Some years ago we added the "missing assembly reference" warning to make users aware of issues that might impact decompilation quality, but could be easily solved with the user's help.

Due to the increasing number of new "special" types, e.g., Span<T>, Memory<T>, AsyncMethodBuilder, etc. all located in different assemblies and also being very different depending on the used version of the framework, we should alert the user in the following cases:

• The DecompilerTypeSystem contains 2 assemblies with the same name, but a different version. Later, this should exclude assemblies that are referenced via extern aliases, but this is a really rare special case, similar to multi-module assemblies, we might get a request to support these roughly once in 10 years.
• The DecompilerTypeSystem contains types that come from different target frameworks. The only exception here is netstandard, because there we do not have an implementation, so netstandard should be handled by following the compatibility matrix.

This idea complements #2036.

[christophwille]

Just to add to this - we have a user base that spans casual users (once every couple of years) to expert users. We should make it easy for once-every-now-and-then users of ILSpy to fall in the pit of success vs not annoying long-time users (who might actually be doing that on purpose).

I will throw in a few ideas:

• Instead of a flat list, show assembly list as a tree (assembly list as a node, no longer choosing a list but having them visible at all times) - and on loading a new assembly, give the user a hint where it should be placed. High effort of change.
• On loading detect that the current list isn't good enough, and show the user a prompt - here is one idea of how that could look like:

[christophwille]

A non-modal approach (we had an interstitial dialog on loading already back with NuGet packages; and we got rid of it) could be implemented too, but in this specific case, it would mean a reload (user-initiated, but still a reload).

Think F12 Developer Tools in a browser - a horizontal pad docked at the bottom of the ILSpy window. It comes with a Console tab, that lists the decompilation output information, with some of it being actionable, like a textual link "Reload with optimized assembly list" much like in this FF screenshot (including hover-tooltip)

Additionally, this dev tools pad could incorporate features from https://github.com/icsharpcode/ILSpy/wiki/Additional-Features-in-DEBUG-Builds that are currently DEBUG-build-only, like the debug steps (as a tab next to Console).