Fixed issue #426 — dtor / destructor not called for (rvalue) struct used in opApply

Fixing the bug turned out to be a lot more work than I expected.

The first obstacle I encountered was that `IRLandingPad` class we use to generate exception handling code expected finally block to be dmdfe's `Statement`. Which temp variables destructor calls are not. So in order to fix the issue, I had to extend `IRLandingPad` API a little bit to have more control over eh codegen.

Once I had the updated API at my disposal, I made the first attempt at fixing the issue. I followed @ibuclaw suggestion and wrapped the destructor calls in `Expression::toElemDtor` in try-finally. While it fixed the issue at hand, the number of generated landing pads had been highly increased. Essentially, it was not possible to write *any* code without triggering eh codegen.

And here goes the third part of my patch. As you probably guessed, the majority of `Expression::toElemDtor()` calls does not need to call any destructors. Previously, we had a classical chicken-and-egg problem: in order to decide whether or not a try-finally is required, we needed a number of temporary variables, but to get it, we had to run the expression codegen at which point we had to know whether a try-finally is required. As a solution, I created an `Expression` tree walker that looks for the temporary variables before the codegen.