[PSyData] Handle derived types in a driver

[hiker]

While the API specific types are replaced with the corresponding plain Fortran types in a driver (e.g. an LFRic field becomes a 1D array), any module included might be using a derived type. For example, the um-physics in LFRic use:

real ::  q(tdims_l%i_start:tdims_l%i_end,tdims_l%j_start:tdims_l%j_end, &
   tdims_l%k_start:bl_levels), &
...
  DO k = 1, bl_levels
    DO j = tdims%j_start, tdims%j_end
      DO i = tdims%i_start, tdims%i_end

The declaration is handled in #2482. The kernel extraction does correctly write the values, e.g.:

      CALL extract_psy_data%PreDeclareVariable("tdims%i_end@atm_fields_bounds_mod", tdims%i_end)
      CALL extract_psy_data%PreDeclareVariable("tdims%i_start@atm_fields_bounds_mod", tdims%i_start)
      CALL extract_psy_data%PreDeclareVariable("tdims%j_end@atm_fields_bounds_mod", tdims%j_end)
      CALL extract_psy_data%PreDeclareVariable("tdims%j_start@atm_fields_bounds_mod", tdims%j_start)

But the driver does not read these files"

  call extract_psy_data%ReadVariable('tdims@atm_fields_bounds_mod', tdims)
  call extract_psy_data%ReadVariable('tdims@atm_fields_bounds_mod', tdims)
  call extract_psy_data%ReadVariable('tdims@atm_fields_bounds_mod', tdims)
  call extract_psy_data%ReadVariable('tdims@atm_fields_bounds_mod', tdims)

We need to fix the driver creation to handle this (as it is in the extraction). An easy alternative solution for a single type would be to add a generic interface for this UM array-bounds type, but the latter would be very limited in its usefulness.