Further frontend performance optimisations

[mlange05]

Another small round of tricks to improve the performance of the sanitize_ir utility and the FP frontend to reduce the frontend processing time for large input subroutines. Primarily, this PR focuses on using fast in-place transformers for the necessary IR sanitisation and avoid using the explicit rescoping for the FParser frontend by attaching the scopes on first IR node creation.

In more detail:

• Use an on-the-fly `Transformer to do inline-comment attachment
• Make all transformers used during sanitisation use inplace=True
• Avoid calling rescope_symbols on the finalised IR when creating subroutines

On the pathological test case we the following improvements:

# On main
In [2]: with config_override({'log-level': 'perf'}):
   ...:     Sourcefile.from_file("apl_arpege_parallel.F90")
[Loki::Frontend] Executed sanitize_input in 0.12s
[Loki::FP] Executed parse_fparser_source in 7.41s
[Loki::Frontend] Executed sanitize_ir in 0.25s
[Loki::Frontend] Executed sanitize_ir in 5.70s
[Loki::Frontend] Executed sanitize_ir in 0.94s
[Loki::FP] Executed parse_fparser_ast in 19.30s
[Loki::Sourcefile] Constructed from apl_arpege_parallel.F90 in 26.83s

# with this PR
In [2]: with config_override({'log-level': 'perf'}):
   ...:     Sourcefile.from_file("apl_arpege_parallel.F90")
[Loki::Frontend] Executed sanitize_input in 0.12s
[Loki::FP] Executed parse_fparser_source in 7.76s
[Loki::Frontend] Executed sanitize_ir in 0.09s
[Loki::Frontend] Executed sanitize_ir in 2.13s
[Loki::Frontend] Executed sanitize_ir in 0.47s
[Loki::FP] Executed parse_fparser_ast in 9.32s
[Loki::Sourcefile] Constructed from apl_arpege_parallel.F90 in 17.27s

Integration note: PR is currently passing ECphysics regression, but not local test base. Will attempt to fix local tests ASAP, but filing draft now to trigger test base. Initial bulk-parse in EC-physics also seems to improve with this.

[github-actions]

Documentation for this branch can be viewed at https://sites.ecmwf.int/docs/loki/234/index.html

[reuterbal]

With #241, #242 and #245 merged, can this be closed?

[mlange05]

Yes, indeed this had been done via separate PRs.