[clang] [clang] Support DecompositionDecl in -ast-print (PR #221711)

[Ran Regev via cfe-commits]

regevran wrote:

> I think the array initialization has a bug; if that's a real pain to address as part of this PR, I think this is still fine as-is because it's forward progress in a lot of ways. But if it can be addressed within this PR, that would be nice. WDYT?

With the help of AI I constructed three different cases that all get ArrayInitLoopExpr node in the AST, only Case 1 belong to this PR:
```cpp
  // Case 1: structured-binding array decomposition
  void f() {
    int arr[3] = {1, 2, 3};
    auto [a, b, c] = arr;
  }
  // -ast-dump: ArrayInitLoopExpr 'int[3]'
  //              `-OpaqueValueExpr -> DeclRefExpr 'arr'

  // Case 2: lambda capturing an array by value
  struct NonTrivial { NonTrivial(); NonTrivial(const NonTrivial&); };
  void f() {
    NonTrivial arr[3];
    [arr] { (void)arr; };
  }
  // -ast-dump: ArrayInitLoopExpr 'NonTrivial[3]'
  //              `-OpaqueValueExpr -> DeclRefExpr 'arr'

  // Case 3: implicit copy constructor initializing an array member
  struct Holder { NonTrivial arr[3]; };
  void f(Holder& h) {
    Holder h2 = h;   // invokes the implicit copy constructor
  }
  // -ast-dump: CXXCtorInitializer Field 'arr'
  //              -ArrayInitLoopExpr 'NonTrivial[3]' //                 -OpaqueValueExpr -> MemberExpr .arr
```

Note: Case 2 and Case 3 do NOT get into `StmtPrinter::VisitArrayInitLoopExpr` from their own personal reasons, only structured-binding array decomposition does.
However, fixing the general case and verifying `getSourceExpr()` is safe to rely on in every case that reaches `StmtPrinter::VisitArrayInitLoopExpr` (not just these three) is beyond this PR, IMHO.

https://github.com/llvm/llvm-project/pull/221711