Convert `jules_pftparm` to a duplicate namelist

[maggiehendry]

Migrate jules_pftparm metadata to jules-shared #41 left an unresolved feature resulting from the implementation of the duplicate namelist functionality in LFRic apps, but not in JULES standalone. The presence of length keyword in the metadata causes the configurator tool to declare the variable as an array, which causes problems when trying to assign the value from config%jules_pftparm to jules_pftparm. For now length=: resides in jules-um & jules-standalone rather than jules-shared, but this is unsatisfactory and a long term solution needs to be sought. After discussion it was decided that treating the jules_pftparm namelist in the same way as LFRic apps i.e. one per PFT would be a better solution, allowing the metadata to be as fully shared as possible. JULES standalone would also benefit from vastly improved management of the namelist inputs for different surface configurations. This issue explores this implementation in JULES standalone.

https://github.com/maggiehendry/jules/tree/115-convert-jules_pftparm-to-a-duplicate-namelist

The upgrade macro has been made more complicated as a result of the need to correct many jules_pftparm items entries that are trigger ignored, before applying the macro required for this ticket. This reinforces the need for better management of this namelist. The reasons for these errors and how they have been rectified in this macro are:

1. Upgrade macro was not robust as they only included existing configurations based on npft = [5, 9, 13] and have not included a default e.g. setting them all to missing data, which would be picked up by the validator macro or the checking routines in JULES at runtime.
   • Added a macro to fix the issue based on the existing macro or set to missing data e.g. fire_mort_io (vn5.3_t872), INFERNO (vn4.4_t136), radiation parameters for scaling against observations (no macro)
2. Namelist has been copied from existing configurations with a different number of PFTs and the trigger ignored values have not been updated to the new configuration.
   • Where the item was of the form [x]*npft, the upgrade macro was robust, an upgrade macro didn't exist or the value was different from the upgrade macro and there weren't too may apps affected in Rose stem, I took a pragmatic approach and corrected these by hand e.g. rose-stem/app/loobos_jules_es_1p0*; vn5.5_t864, vn5.3_t766, vn4.8_t541
3. Error when applying the upgrade macro, but existing upgrade macro is robust.
   • Repeated the existing upgrade macro in this upgrade macro.