Instead of storing a variant with specific types, store parser::Block as
the body. Add two access functions to make the traversal of the nest
simpler.

This will allow storing loop-nest sequences in the future.

Move the parse tree utility function
semantics::getDesignatorNameIfDataRef to Parser/tools.h and rename it to
comply with the local style.

If there is a call inside a TEAMS construct, and that call contains a
DISTRIBUTE construct, the DISTRIBUTE region is considered to be enclosed
by the TEAMS region (based on the dynamic extent of the construct).
Currently, Flang diagnoses this as an error, which is incorrect.
For eg :
```
 subroutine f
  !$omp distribute
  do i = 1, 100
    ...
  end do
end subroutine

subroutine g
  !$omp teams
  call f ! this call is ok, distribute enclosed by teams
  !$omp end teams
end subroutine
```
This patch adjusts the nesting check for the OpenMP DISTRIBUTE
directive. It retains the error for DISTRIBUTE directives that are
incorrectly nested lexically but downgrades it to a warning for orphaned
directives to allow dynamic nesting, such as when a subroutine with
DISTRIBUTE is called from within a TEAMS region.

Co-authored-by: Chandra Ghale <ghale@pe31.hpc.amslabs.hpecorp.net>

Parse them as "invalid" OmpObjects, then emit a diagnostic in semantic
checks.

…rective

This makes accessing directive components, such as directive name or the
list of clauses simpler and more uniform across different directives. It
also makes the parser simpler, since it reuses existing parsing
functionality.

The changes are scattered over a number of files, but they all share the
same nature:
- getting the begin/end directive from OpenMPLoopConstruct,
- getting the llvm::omp::Directive enum, and the source location,
- getting the clause list.

OpenMPBlockConstruct, somewhat confusingly, represents most but not all
block-associated constructs. It's derived from OmpBlockConstruct, as are
all the remaining block-associated constructs.

It does not correspond to any well-defined group of constructs. It's the
collection of constructs that don't have their own types (and those that
do have their own types do so for their own reasons).

Using the broader OmpBlockConstruct in type-based visitors won't cause
issues, because the specific overloads (for classes derived from it)
will always be preferred.

This allows not having the END CRITICAL directive in certain situations.
Update semantic checks and symbol resolution.

The structure is
- OmpBeginDirective (aka OmpDirectiveSpecification)
- Block
- optional<OmpEndDirective> (aka optional<OmpDirectiveSpecification>)

The OmpBeginDirective and OmpEndDirective are effectively different
names for OmpDirectiveSpecification. They exist to allow the semantic
analyses to distinguish between the beginning and the ending of a block
construct without maintaining additional context.

The actual changes are in the parser: parse-tree.h and openmp-parser.cpp
in particular. The rest is simply changing the way the directive/clause
information is accessed (typically for the simpler).

All standalone and block constructs now use OmpDirectiveSpecification to
store the directive/clause information.

Create these new files in flang/lib/Semantics:
  openmp-utils.cpp/.h         - Common utilities
  check-omp-atomic.cpp        - Atomic-related checks
  check-omp-loop.cpp          - Loop constructs/clauses
  check-omp-metadirective.cpp - Metadirective-related checks

Update lists of included headers, std in particular.

---------

Co-authored-by: Jack Styles <jack.styles@arm.com>