A structure constructor used in (or as) the default component
initializer for a PDT derived type component needs to traverse the scope
of the right PDT instantiation.

Fixes https://github.com/llvm/llvm-project/issues/167337 and fixes
https://github.com/llvm/llvm-project/issues/167573.

This PR adds support for the NOTIFY specifier in the image selector as
described in the 2023 standard, and add checks for the NOTIFY_TYPE type.

When folding intrinsic function calls for types like REAL(2) that don't
have host math library support, we convert them to a type that has
greater range and precision, call a host math library routine that does
exist, and convert the result back to the original result type. The
folding of this second conversion can elicit floating-point warnings
(usually overflow) that are somewhat unclear to the user. Add support
for adding contextual information to these warnings.

When a generic procedure reference does not match any of its specific
procedures, run through them and emit the errors for each attempted
match, so that the user has more information to resolve the problem by
adjusting the actual arguments.

Fix a false positive "NULL can't be an operand here" error message
arising in a defined generic interface for an intrinsic operator (==)
with multiple spellings.

Fixes https://github.com/llvm/llvm-project/issues/163255.

Replace more parse tree references to "thing" and "value()" with usage
of the parser::Unwrap<> template function.
Add parser::UnwrapRef<> as an alias for DEREF(Unwrap<>()).

Audit the use of std::optional<bool> as a tri-state logical value in
flang, correct a couple cases that need ".value_or()", add some explicit
".has_value()" calls, and document the possible pitfalls.

As a common language extension, this compiler accepts a structure
constructor whose first value has no keyword and whose type matches an
ancestral type as if the constructor had had a keyword whose name was
the ancestral type. For example, given
  TYPE PARENT; REAL X; END TYPE
  TYPE, EXTENDS(PARENT) :: CHILD; END TYPE
we accept the nonconforming constructor "child(parent(1.))" as if it had
been the conforming "child(1.)" or "child(parent=parent(1.))".

The detection of this case needs to be constrained a bit to avoid a
false positive misinterpretation of conforming code in the case where
the actual first component of the derived type is a POINTER or
ALLOCATABLE whose type and rank would allow it to correspond with the
keywordless first value in the component value list.

Fixes https://github.com/llvm/llvm-project/issues/161887.

The compiler currently emit an error about the lack of an explicit
procedure interface when an external procedure that is called via an
implicit interface is known to have an dummy argument with a CUDA data
attribute, even when the corresponding actual argument does have a CUDA
data attribute. This behavior is inconsistent with what happens when
such a call is to an external in another source file and its definition
is not visible -- the compiler silently accepts an actual argument with
a CUDA data attribute across the implicit interface.

Harmonize this situation so that an actual argument with a CUDA data
attribute in a reference to a procedure with an implicit interface
elicits a usage warning encouraging the use of explicit interfaces. Only
when the procedure's definition is visible, and incompatible, will an
error message appear.

The code in expression semantics that catches a call to an impure
procedure in a PURE context misses calls to impure intrinsics, since
their designators have a SpecificIntrinsic rather than a Symbol. Replace
the current check with a new one that uses the characteristics of the
called procedure, which works for both intrinsic and non-intrinsic
cases.

Testing this change revealed that an explicit INTRINSIC statement wasn't
doing the right thing for extension "dual" intrinsics that can be called
as either a function or as a subroutine; the use of an INTRINSIC
statement would disallow its use as a subroutine. I've fixed that here
as well.

Fixes https://github.com/llvm/llvm-project/issues/157124.