[flang][OpenMP] Memory leak in first private declaration of a derived type.

Consider the following code:

```
PROGRAM DRIVER
use omp_lib
IMPLICIT NONE
INTEGER, PARAMETER :: NVAL = 2000
TYPE TCONTAINER
REAL(KIND=8), ALLOCATABLE :: ARR(:)
END TYPE TCONTAINER
TYPE(TCONTAINER) :: obj
INTEGER :: idx
ALLOCATE (obj%ARR(NVAL))
do idx=1,4
!$OMP PARALLEL FIRSTPRIVATE (obj)
write(*,*), 'thread', omp_get_thread_num()
!$OMP END PARALLEL
enddo
DEALLOCATE (obj%ARR)
END PROGRAM DRIVER
```

Compiling with a recent version of upstream Flang and running this code with valgrind on an icelake machine (x86):

```
[scamp]$ flang test.F90 -o test -fopenmp -g
[scamp]$ export OMP_NUM_THREADS=2
[scamp]$ valgrind --leak-check=full ./test
==3579486== Memcheck, a memory error detector
==3579486== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==3579486== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info
==3579486== Command: ./test
==3579486==
thread 0
thread 1
thread 0
thread 1
thread 0
thread 1
thread 0
thread 1
==3579486==
==3579486== HEAP SUMMARY:
==3579486== in use at exit: 210,753 bytes in 24 blocks
==3579486== total heap usage: 796 allocs, 772 frees, 1,756,205 bytes allocated
==3579486==
==3579486== 64,000 bytes in 4 blocks are definitely lost in loss record 11 of 13
==3579486== at 0x4C3E2E1: malloc (vg_replace_malloc.c:446)
==3579486== by 0x501C0E6: Fortran::runtime::Descriptor::Allocate(long*) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD3B47: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD1ABC: Fortran::runtime::DerivedAssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD3E6F: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD65BC: _FortranAAssign (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x40014E4: _QQmain..omp_par (test.F90:8)
==3579486== by 0x4132178: __kmp_invoke_microtask (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40AE59E: __kmp_invoke_task_func (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40A8BC4: __kmp_fork_call (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40986FC: __kmpc_fork_call (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40012DF: _QQmain (test.F90:8)
==3579486==
==3579486== 64,000 bytes in 4 blocks are definitely lost in loss record 12 of 13
==3579486== at 0x4C3E2E1: malloc (vg_replace_malloc.c:446)
==3579486== by 0x501C0E6: Fortran::runtime::Descriptor::Allocate(long*) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD3B47: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD1ABC: Fortran::runtime::DerivedAssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD3E6F: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD65BC: _FortranAAssign (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x40014E4: _QQmain..omp_par (test.F90:8)
==3579486== by 0x4132178: __kmp_invoke_microtask (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40AE59E: __kmp_invoke_task_func (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40AD1FD: __kmp_launch_thread (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x4111BF7: __kmp_launch_worker(void*) (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x65521C9: start_thread (in /usr/lib64/libpthread-2.28.so)
==3579486==
==3579486== LEAK SUMMARY:
==3579486== definitely lost: 128,000 bytes in 8 blocks
==3579486== indirectly lost: 0 bytes in 0 blocks
==3579486== possibly lost: 0 bytes in 0 blocks
==3579486== still reachable: 82,753 bytes in 16 blocks
==3579486== suppressed: 0 bytes in 0 blocks
==3579486== Reachable blocks (those to which a pointer was found) are not shown.
==3579486== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3579486==
==3579486== For lists of detected and suppressed errors, rerun with: -s
==3579486== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
[scamp]$
```
There's definitely a memory leak associated with the first private declaration of 'obj' at the parallel region. Analyzing the assembly with "-S" and comparing against the valgrind output, I believe for the parallel region, there's a '_FortranAAssign' that allocates at the beginning of the parallel region, but there's not corresponding free for that allocation, leading to the leak.

Start with the reproducer in test.F90, compile it with -fopenmp and -g, and run it under Valgrind. Inspect the generated assembly around _FortranAAssign in the parallel region and the corresponding runtime allocation path. Done means repeated FIRSTPRIVATE use of the derived type no longer leaves the reported allocations leaked.

Written by the indexing model from the issue text.