(Closes #2422) add support for routine interfaces

[arporter]

Adds support for interfaces of the form:

interface my_brilliant_routine
  module procedure :: brilliant1, brilliant2
  procedure :: also_good
end interface

[arporter]

Initially I had the new GenericInterfaceSymbol store a list of RoutineSymbols. However, that then caused trouble when deep-copying a SymbolTable as we'd have to update the references to the RoutineSymbols within the GenericInterfaceSymbol. I've therefore elected to store a list of str instead of Symbols but am happy to discuss.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (699ceb2) 99.85% compared to head (9760576) 99.85%.

❗ Current head 9760576 differs from pull request most recent head 02bc8a8. Consider uploading reports for the commit 02bc8a8 to get more accurate results

Additional details and impacted files

@@           Coverage Diff            @@
##           master    #2435    +/-   ##
========================================
  Coverage   99.85%   99.85%            
========================================
  Files         352      353     +1     
  Lines       47334    47500   +166     
========================================
+ Hits        47264    47431   +167     
+ Misses         70       69     -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[arporter]

Ready for a first look from either @rupertford or @sergisiso. This only adds the PSyIR support - it doesn't extend KernelModuleInlineTrans to make use of it.

[sergisiso]

@arporter Good start, I have some concerns about losing information e.g. module keyword and mixed procedure/subroutine interfaces, so it would be good to add tests for all these (see inline comments).

Also regarding:

Initially I had the new GenericInterfaceSymbol store a list of RoutineSymbols. However, that then caused trouble when deep-copying a SymbolTable as we'd have to update the references to the RoutineSymbols within the GenericInterfaceSymbol. I've therefore elected to store a list of str instead of Symbols but am happy to discuss.

I think I am of the opposite opinion, References, Calls, Types, precision have "references" to symbols so they survive renamings and can be queried without a lookup. I think it would be consistent to also keep references to the RoutineSymbols here (unless the implementation gets very complex).

[arporter]

Integration tests all green now. I've manually checked coverage as CodeCov is being very slow - it all seems fine. Ref. guide now has 17 warnings but the additional one is due to the new namedtuple and isn't anything we can fix. Ready for another look now.

[sergisiso]

@arporter Apologies for taking a long time to review this. Almost everything looks good now, I just still think the interface replace should be done with a symbol renaming now that everything points to the same symbol object. Also resolve the merging conflicts and the suggested pylint/pycodestyle issues and then this can go ahead.

[arporter]

Thanks very much for pointing out what I was missing with the symbol renaming. Integration tests were fine. CI-permitting, this is ready for another look.

[sergisiso]

Thanks @arporter All requested changes have been done and all tests, integration, formatting and codecov are now green. This is ready to be merged.