Refactor PSyKAl workflow

[sergisiso]

With #1010 we now have PSyIR nodes and PSyIR symbols throughout the LFRic workflow, which currently consists of:

1. parsing
2. generate psy-layer (parses kernel metadata and creates initial loops and calls)
3. transformation script (some just enable booleans, .e.g. colouring, distributed mem ...)
4. generate declarations
5. generate initialisations
6. lowering (includes argordering and second stage of some transfomrations)

This has 2 problem:

• It is hard to deal with symbols, when operating with them it is unclear if we are at a point before or after each symbol is created, so we have "find_or_create" all over the place, duplicating the definition of the types. Having declarations and initialisation separated also means we have almost symetric implementations (all declarations but the loop variables need initialisations) however we need to do many lookups to find them.
• It is hard to do transformations because if a previous transformation is just a boolean and not reflected in the PSyIR, the new transformation also needs to be a boolean to place it later, or worst, encode knowledge about all possible transformations and what changes the implicate for itself (which is not scalable with the number of transformations)

I propose simplifying the workflow to:

parsing
generate psy-layer (loops and kernels)
generate declarations + initialisations
transformation script (do it in-place when possible)
lowering

Changing the location of the declarations+inits is realtively simple, the big change here is in some transformations because they now have the responsibility of cleaning up the symbols they replace and add the new ones, including their initialisations (e.g. colourmaps). But as a benefit:

• they become more composable, they don't need to know about any other transformations, the PSyIR they recieve is the truth.
• they are better encapsulated: the symbols, initialisations, and changes they introduce are all in the same file, and not scattered through the code

The con of this workflow is that the order of transformations matter more (because they are not hardcoded in a specific position the lowering).

Note: ArgOrdering also has duplications with "generate declarations", it does "find_or_create" again and interface setting again, I will leave this for a second stage.

@arporter @hiker @TeranIvy we have discussed this before, but any comments on this proposal? (the change won't come quick, specially moving the distributed memory logic inside a transformation could be hard, but I will start exploring this)