Rework implicit allocation in constructors

[dcodeIO]

As reported in #1225 some weirdness is happening in constructors, caused by late this allocations. While investigating, it turned out that this mechanism is connected to quite a few other assumptions made by inlining and reference counting, so I decided to implement a new but more conservative mechanism.

With the change, the allocation is injected right at the start of the constructor as soon as any code path requires it (falls-through or accesses this). As a side-effect, the following special cases are no longer allowed:

• A constructor with an explicit return must not access this. Not yet sure if this can become a warning instead of an error.
• A class with an explicitly returning constructor must be sealed since super calls in this scenario will break due to the resulting this mismatch.

On the upside, implicit allocations in constructors are now guaranteed to be performed exactly once, reducing code size in scenarios where this is first accessed in branches.

fixes #1225

[dcodeIO]

This now generally allows returning in constructors as long as this is returned. If something else than this is returned somewhere, the class must be @sealed. In any case, if something else than this is returned but this is being accessed somewhere in the constructor or the constructor falls through, a pedantic diagnostic is emitted hinting at the potentially dropped this allocation.

[dcodeIO]

Also renamed @sealed to @final now, so we can reuse it for methods or anything else final as well eventually.