(Closes #2202) Update the generation of Fortran declarations to observe dependencies

[arporter]

This is a relatively simple PR - it takes the inter-dependence handling out of _gen_param_decls and puts it into gen_decls. This also then means we can delete _gen_param_decls. I've added tests for the various tricky cases described in the original Issue and they all pass now :-)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (c9a9da4) to head (adca257).
⚠️ Report is 6 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #3344   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          399       399           
  Lines        56173     56174    +1     
=========================================
+ Hits         56173     56174    +1     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[arporter]

The NEMO ITs failed because of character variables:

Symbol Table of Container 'test_mod':
-------------------------------------
DataSymbol:
  cdwmo: DataSymbol<UnsupportedFortranType('CHARACTER(LEN = ilenwmo), DIMENSION(:), POINTER, PUBLIC :: cdwmo'), Unknown>
  ilenwmo: DataSymbol<Scalar<INTEGER, UNDEFINED>, Static, initial_value=Literal[value:'58', Scalar<INTEGER, UNDEFINED>], constant=True>

(Pdb) cdwmo = table.lookup("cdwmo")
(Pdb) cdwmo.get_all_accessed_symbols()
set()
(Pdb) cdwmo.datatype.declaration
'CHARACTER(LEN = ilenwmo), DIMENSION(:), POINTER, PUBLIC :: cdwmo'

I was proceeding to try and do something with the parse tree in UnsupportedFortranType but actually, it would probably be better to work on populating the partial_datatype in this case.

[arporter]

Marking this as blocked for the moment because I want to investigate adding support for a CharacterType with a length property.

[arporter]

Although things are now better, complex types are still a problem - I've added a (failing) test which demonstrates this.

[arporter]

All the ITs passed. However, I've realised that the order of output is not guaranteed - if more than one Symbol has all its dependencies declared at a given point then we should sort those Symbols and declare them in alphabetical order.