Fix #4059: treat a Deconstruct out argument as a definition

[siegfriedpammer]

Fixes #4059.

Two deconstructions of the same source type in one method are not recognized: the first one alone
decompiles correctly, but as soon as a second follows, both fall back to raw Deconstruct calls,
because csc reuses the same two out-slot temporaries and hands them to the second call in the
opposite order.

Why splitting the temporaries did not happen

ReachingDefinitionsVisitor does not track address loads, so a variable that is only ever written
through its address - which is every out slot - stays potentially uninitialized for its whole
life. SplitVariables.GroupStores merges all such loads of one variable into a single
representative, so the two deconstructions end up in one live range and neither can be matched.

The same holds for out arguments in general; it only becomes visible for Deconstruct, where
pattern matching depends on the split.

The fix

An ldloca in argument position > 0 of a Deconstruct call is treated as a definition: it kills
the definitions reaching it and becomes the one that reaches the following loads. That reuses the
existing store machinery, so it stays flow-sensitive - where two such calls join, both reach the
load and are merged again, which a flow-insensitive rule would get wrong.

IL cannot express an address that is assigned without being read first; out is a C# convention
over ref. So the qualifying address loads have to be named one by one, and a Deconstruct
method written in IL could read its argument before assigning it. That possibility is knowingly
ignored - C#'s definite assignment rules rule it out for anything a compiler emits.

SplitVariables itself is unchanged: its HandleLoad on such an ldloca now runs against the
post-store state and merges the instruction with itself.

Tests

The TwoBackToBackDeconstructs_Custom case that #4059 was filed from is checked in commented out;
this enables it. It fails on all eight compiler configurations before the change and passes after.

ICSharpCode.Decompiler.Tests: 3604 tests, no failures, 45 skipped (Windows-only configurations).

Prepared by an AI agent (Claude, claude-opus-5, via Claude Code) and reviewed by @siegfriedpammer.

[dgrunwald]

This needs proper investigation of how it interacts with the derived class (SplitVariables.GroupStores) -- and especially the partial support for ref locals that has.