`Routine.update_parent_symcol_table` can fail if the first child of a CodeBlock's subroutine is a comment

[LonelyCat124]

Before I fix this I want to fix fparser 505 in case it resolves anything.

This MVE:

module test

    contains

        subroutine routine()
            procedure (halo_exchange_routine) :: exchange_halo_group
        end subroutine

        subroutine routine1(a, b, c)
            integer, intent(inout) :: a, b, c

            call routine2()
        end subroutine

        subroutine routine2()

        end subroutine

end module

with psyclone --keep-comments mve.F90 results in

Traceback (most recent call last):
  File "/home/aidan/base-env/bin/psyclone", line 42, in <module>
    main(sys.argv[1:])
  File "/home/aidan/PSyclone/src/psyclone/generator.py", line 733, in main
    code_transformation_mode(
  File "/home/aidan/PSyclone/src/psyclone/generator.py", line 942, in code_transformation_mode
    psyir = reader.psyir_from_file(input_file)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/aidan/PSyclone/src/psyclone/psyir/frontend/fortran.py", line 226, in psyir_from_file
    psyir = self._processor.generate_psyir(tree)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/aidan/PSyclone/src/psyclone/psyir/frontend/fparser2.py", line 1206, in generate_psyir
    self.process_nodes(node, [parse_tree])
  File "/home/aidan/PSyclone/src/psyclone/psyir/frontend/fparser2.py", line 3125, in process_nodes
    psy_child = self._create_child(child, parent)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/aidan/PSyclone/src/psyclone/psyir/frontend/fparser2.py", line 3231, in _create_child
    return handler(child, parent)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/home/aidan/PSyclone/src/psyclone/psyir/frontend/fparser2.py", line 6072, in _program_handler
    self.process_nodes(file_container, node.children)
  File "/home/aidan/PSyclone/src/psyclone/psyir/frontend/fparser2.py", line 3125, in process_nodes
    psy_child = self._create_child(child, parent)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/aidan/PSyclone/src/psyclone/psyir/frontend/fparser2.py", line 3231, in _create_child
    return handler(child, parent)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/home/aidan/PSyclone/src/psyclone/psyir/frontend/fparser2.py", line 6038, in _module_handler
    self.process_nodes(parent=container, nodes=module_subprograms)
  File "/home/aidan/PSyclone/src/psyclone/psyir/frontend/fparser2.py", line 3166, in process_nodes
    parent.addchild(psy_child)
  File "/home/aidan/PSyclone/src/psyclone/psyir/nodes/node.py", line 915, in addchild
    self._children.append(child)
  File "/home/aidan/PSyclone/src/psyclone/psyir/nodes/node.py", line 201, in append
    self._set_parent_link(item)
  File "/home/aidan/PSyclone/src/psyclone/psyir/nodes/node.py", line 171, in _set_parent_link
    node.update_parent_symbol_table(self._node_reference)
  File "/home/aidan/PSyclone/src/psyclone/psyir/nodes/routine.py", line 357, in update_parent_symbol_table
    name = str(routine.children[0].children[1])

When adding something to the tree (routine2 node? I think) we end up in update_parent_symbol_table, which fails on this block

                    for routine in routines:
                        name = str(routine.children[0].children[1])
                        if name == self.name:
                            raise GenerationError(
                                    f"Can't add routine '{self.name}' into"
                                    f" a scope that already contains a "
                                    f"CodeBlock representing a routine "
                                    f"with that name.")

as routine.children[0] is a Comment for the routine codeblock subroutine, wheras we're expecting the <class 'fparser.two.Fortran2003.Subroutine_Stmt'> of the SubProgram statement. This therefore only happens with --keep-comments

[LonelyCat124]

@schreiberx This should be fixed (indirectly) by stfc/fparser#509 I think so I will not work on it until that is merged into fparser and I will check if this case still fails.

[LonelyCat124]

The fparser PR didn't fix this in the end, so this can still happen. If its critical i'll start to work on it since it should be a small fix.