[flang] Handle AssocEntityDetails in mis-parsed function reference

Fix issue flang-compiler/f18#574.
Array references can be mistaken for function references during
parsing. This is handled and fixed by semantics. however, if the
symbol in the misparsed array reference was construct associated,
then semantics was not handling the case correctly because
semantics was only expecting `ObjectEntityDetails`.
It was not possible to change the related `GetUltimate` into
`GetAssociationRoot` because associated symbols are not always
associated to another symbol (variable) but may be assoicated to
an expression. Hence, this change allow `AssocEntityDetails` to
be also accepted when dealing with array references misparsed as
function references.

Original-commit: flang-compiler/f18@b6a8b5f42b
Reviewed-on: https://github.com/flang-compiler/f18/pull/672
Tree-same-pre-rewrite: false

flang/lib/semantics/expression.cc

@@ -1883,7 +1883,8 @@ static void FixMisparsedFunctionReference(
             },
             proc.u)}) {
       Symbol &symbol{origSymbol->GetUltimate()};
-      if (symbol.has<semantics::ObjectEntityDetails>()) {
+      if (symbol.has<semantics::ObjectEntityDetails>() ||
+          symbol.has<semantics::AssocEntityDetails>()) {
         if constexpr (common::HasMember<common::Indirection<parser::Designator>,
                           uType>) {
           CheckFuncRefToArrayElementRefHasSubscripts(context, funcRef);

flang/lib/semantics/resolve-names.cc

@@ -5063,7 +5063,8 @@ void ResolveNamesVisitor::HandleProcedureName(
       return;  // reported error
     }
     if (IsProcedure(*symbol) || symbol->has<DerivedTypeDetails>() ||
-        symbol->has<ObjectEntityDetails>()) {
+        symbol->has<ObjectEntityDetails>() ||
+        symbol->has<AssocEntityDetails>()) {
       // these are all valid as procedure-designators
     } else if (symbol->test(Symbol::Flag::Implicit)) {
       Say(name,