Decompiler takes quadratic time for large array initializers

[dgrunwald]

During profiling I found (at least) two hotspots caused by long array initializers interacting badly with the NRefactory AST design.

1. TranslateArrayInitializer()
   The loop condition

while (container.Count > 0 && container.Peek().Elements.Count == dimensionSizes[container.Count - 1]) {
    container.Pop();
}

consumes a large amount of time, because the Elements.Count property getter is actually O(N). The while-loop condition is false most of the time, but there's an outer loop adding to container.Peek().Elements, so an array initializer with N elements performs N get_Count calls, taking O(N²) overall time.

2. InsertSpecialsDecorator.WriteSpecialsUpToRole()
   Here we are looking for the non-existing comma tokens. For each place where there should be a comma we scan all following children, so that's quadratic. The problem is hard to fix given the InsertSpecialsDecorator design, but an easy workaround would be to emit the comma tokens it is looking for.

In the case of the NRefactory roundtrip test, fixing these performance bugs should have a significant impact on the overall decompilation time (at least 25%).

[dgrunwald]

I think 27efe1b fixed this; I can't think of a better fix that doesn't involve changing the whole AST design.