ftn: lastprivate on a parallel do in a target region gives a wrong final value when the variable is firstprivate in the target region (not mapped)

! # Draft finding: omp52-w-lastprivate-parallel-in-seq-loop on cce19
!
! - compiler: cce19
! - toolchain: cce19; arch: gfx942; machine: tuolumne; memory mode: unified; opt: -O2
! - program: catalog omp52-w-lastprivate-parallel-in-seq-loop (f90, version 52, sha256 b5e25088c4a2a5e8)
! - expected: check=pass (trusted; elision + model)
! - actual: wrong_answer check=fail (check_fail: ran_on_host=0 check=fail)
! - verdict: compiler_bug by rule R20-runtime-bug: a legal program fails at run time, deterministically, against an expected value
!   from two or more independent sources with an executed witness, and another toolchain, mode, arch or the elision gives the
!   expected value
! - reason: expected trusted check=pass (elision + model): stored main verdict: elision + model agree; witnesses: afar/gfx942/copy,
!   afar/gfx942/copy (port:omp52-c-w-lastprivate-parallel-in-seq-loop), afar/gfx942/unified, afar/gfx942/unified
!   (port:omp52-c-w-lastprivate-parallel-in-seq-loop), elision
! - citations: RUL-DERIVED-NEEDS-EXECUTION (rulings.md); RUL-WITNESS-PER-MODE (rulings.md);
!   RUL-SAME-COMPILER-RUNS (rulings.md); RUL-PRESENCE-WITNESS (rulings.md); RUL-METAMORPHIC-OTHER-FAMILY
!   (rulings.md)
! - legality: legal: offload.engine.prerun.check accepts it (rerun: offload.engine.rules with the
!   race rule and the restriction checks, and the AFAR flang front end, not under test here); no
!   compiler under test, gfortran or gcc is a legality witness
! - witnesses: afar/gfx942/copy, afar/gfx942/copy (port:omp52-c-w-lastprivate-parallel-in-seq-loop), afar/gfx942/unified,
!   afar/gfx942/unified (port:omp52-c-w-lastprivate-parallel-in-seq-loop), elision
! - withdrawn: none
!
! Generated by compliance.widen (OpenMP 5.2, free-form Fortran; catalog widening). Do not edit.
! id: omp52-w-lastprivate-parallel-in-seq-loop
! primary atom: pair.omp.clause.lastprivate+base.device.parallel_in_seq_loop
! atoms: pair.omp.clause.lastprivate+base.device.parallel_in_seq_loop, omp.clause.lastprivate, base.device.parallel_in_seq_loop
! legal: yes
! observable: yes
! ran_on_host: inside the target region of interest
! evidence: construct
! needs: none
! std: f2008
! feature: lastprivate on a parallel do nested in a sequential loop of a target region
! spec: the parts' own programs
! pair of: omp.clause.lastprivate + base.device.parallel_in_seq_loop (each has a program of its own)
program wide_prog
  use omp_lib, only: omp_is_initial_device
  implicit none
  integer, parameter :: n = 64
  integer :: a(n), b(n), ref(n)
  integer :: k, last
  integer :: i, host_flag
  logical :: ok
  do i = 1, n
    a(i) = i
    b(i) = 0
    ref(i) = 2*i + 1
  end do
  host_flag = 1
  !$omp target map(to: a) map(tofrom: b, host_flag)
  host_flag = merge(1, 0, omp_is_initial_device())
  do k = 1, 3
    !$omp parallel do lastprivate(last)
    do i = 1, n
      last = a(i) + k
    end do
    !$omp end parallel do
    b(k) = last
  end do
  !$omp end target
  ok = all(b(1:3) == [n + 1, n + 2, n + 3])
  print '(a,i0,a,a)', 'RESULT ran_on_host=', host_flag, ' check=', merge('pass', 'fail', ok)
end program wide_prog
! spec (requirement): With lastprivate, the original list item is assigned the value of the new list item from the
!   sequentially last iteration.
! "the value of each new list item from the sequentially last iteration of the associated loops, or the lexically last
!   structured block sequence associated with a sections construct, is assigned to the original list item." (5.2
!   §5.4.5 p.115 l.14-16)
! spec (requirement): A scalar referenced in a target region and not mapped is firstprivate in it, so the original
!   list item of the inner lastprivate is the target region's copy.
! "If the above rules do not apply then a scalar variable is not mapped but instead has an implicit data-sharing
!   attribute of firstprivate" (5.2 §5.8.1 p.149 l.8-9)
! spec (this program): last is firstprivate in the target region and lastprivate on each parallel do of the sequential
!   k loop, so b(k) must take the value a(n) + k (65, 66, 67) from the final iteration; ftn gives a wrong final value.