Long-term evolution of the ICSharpCode.Decompiler model and pipeline

[siegfriedpammer]

We are reaching a point where in some parts of the decompiler there are only bolt-on solutions are possible or where the decompiler architecture has serious performance problems. We will use this issue to track and discuss ideas for possible changes/refactorings to improve the decompiler architecture:

There are three areas:

ILReader

• Improve ILReader and typesystem interactions: resolving of TypeRefs, TypeSpecs and MemberRefs (Performance idea: ILReader / type system #1203)
• Reduce the amount of ILInlining required in the Pipeline by constructing simple ILAst trees in ILReader (same as #1430 appear again #1513) (implemented by Optimize ILReader: don't create stack slots if we can directly created inlined ILAst #2766)
• ILReader gets implicit conversions subtly wrong #901 -- This is low-priority as it only affects C++/CLI and obfuscated code and seems not worth the effort, as we would have to implement the quirks RyuJIT does when importing IL, just to be "bug-compatible".

ILAst model

• Simplify modelling of conditional branches in the "basic block stage" of the decompiler pipeline:

if (condition) true-branch-instruction
false-branch-instruction
=>
if (condition) true-branch-instruction else false-branch-instruction 

One gain is that we only need to look at the last instruction of each block.

• Explicitly model implicit truncations
  stloc/stobj instructions storing types smaller than i32 will implicitly truncate the value. Inlining such stores leads to bugs like Missing cast for coerced local variable stores #2847. It would be easier to preserve semantics if such truncations were explicit in the ILAst.

Decompiler pipeline

• We have some pass-ordering problems in the "basic block" stage of the pipeline, which bites us whenever a new feature or pattern is added to the pipeline: There are multiple instances of ControlFlowSimplification, ILInlining and SplitVariables used in pipeline and some transforms depend heavily on IL inlining or variable splitting being done before they are run. This makes changing the order or adding new transformations in that part of the decompiler very difficult. We need to look into finding a model similar to IBlockTransform and IStatementTransform for the early stages of the pipeline.
• Make InlineReturnTransform unnecessary: This should already be done by ControlFlowSimplification. While fixing ICSharpCode.ILSpy.AssertionFailedException #2503 I discovered that we leave some leave instructions uninlined after the async/yield transforms as InlineReturnTransform never runs after them.

[dgrunwald]

ILReader: #901 would be a massive change and is probably not worth it.
#1203 and #1513 are only performance optimizations, but are doable without a massive ILReader rewrite. I think they're part of our most promising performance optimizations (along with #1204 which should be even lower-hanging).