Known LFRic kernel data symbols

[rupertford]

When an LFRic kernel is parsed we create a generic PSyIR representation of the kernel. However, we know the types of data passed into the kernel so can and should add that information in.

Doing this is the initial step towards transforming LFRic kernel code into a more DSL-like form which we can better reason about in transformations. In particular I am working towards recognising scatters and gathers of field data at a particular level which need to be removed as part of the transformation of LFRic code to a kinner form.

Examples of LFRic-specific data symbols (which will subclass DataSymbol) are:

FieldDataSymbol, NdofsSymbol, NlayersSymbol. DofmapSymbol.

Note, the names are an illustration and are subject to change

Once the kernel argument data symbols are transformed we can think about how we link an instance of FieldDataSymbol to associated NdofsSymbol and DofmapSymbol instances, and MatrixSymbol to two NdofsSymbol instances as well as recognising types of loops (which we can work out due to their bounds now being a particular LFRic type.

[rupertford]

Created branch 873_lfric_kernel_data_symbols

[rupertford]

At the moment we have a DynKern class in LFRic which is a CodedKern and a CodedKern has a get_kernel_schedule() method which parses the underlying Fortran AST with fparser2reader to create a PSyIR schedule. So, the first thing to do is to specialise get_kernel_schedule in DynKern so that we can add in an additional phase which will translate from PSyIR to LFRicPSyIR.

[rupertford]

As things stand PSyclone has no explicit knowledge about arguments in LFRic kernels. Therefore, the first step is to add this knowledge in. I am doing this by creating objects which capture the required interface information for each argument. I've done this by specialising ArgOrdering with a new class called KernelInterface. This returns a list of interface objects which relate to the kernel arguments. The objects contain information such as scalar or array, integer, real ..., precision kind and intent. They will also contain information as to how the arguments relate to each other e.g. a field's array size argument and its associated dofmap.

This will not be the final and best way to capture this information but seeing as we don't capture it at all at the moment and that it serves my purposes I think it is OK. I will make this work and its use in checking the validity of kernel arguments (this relates to #288 but only for LFRic) the subject of a first PR and then continue to develop within this PR.