Required river related developments

This issue documents the developments identified during & since the creation of the Rivers standalone executable used in LFRic-GC coupled via OASIS to the LFRic atmosphere-land component. Development began under MOSRS. The relevant tickets are listed below with work still required from each described. These enhancements would reduce the dependencies of the executable and naturally break the processing of the rivers ancillary data into smaller more manageable chunks.

**#89 identified the need to be able to initialised `inland_flow_rp` & `rivers_outflow_rp` to a constant instead of using a dump or a file. This is required as a matter of urgency.**

[mosrs-jules:#1252 - Separate out fluxes used by rivers to simplify Rivers-standalone build](https://code.metoffice.gov.uk/trac/jules/ticket/1252)
The Rivers-standalone build added with [~~mosrs-jules:#1084~~](https://code.metoffice.gov.uk/trac/jules/ticket/1084) has each routine explicitly specified in **make-river.cfg** to identify areas where Rivers-standalone can be simplified and to prevent the dependencies from inadvertently growing. This ticket will simplify the Rivers-standalone build by separating out the fluxes use by the rivers from **fluxes_mod** to **river_fluxes_mod**.

`init_drive` could also be made more modular and split into a Rivers-standalone version calling the same routines as necessary.

[mosrs-jules:#1558 - Refactor init_rivers_props and the processing of the rivers ancillary data](https://code.metoffice.gov.uk/trac/jules/ticket/1558)
While the file size of `init_rivers_props` was vastly reduced under [~~mosrs-jules:#1525~~](https://code.metoffice.gov.uk/trac/jules/ticket/1525) the routines it calls are too large and require splitting up to be coherent, more easily understood and to improve code management.

The namelist jules_rivers_props should be split into at least two; `jules_rivers_grid` & `jules_rivers_props` akin to `jules_input_grid` and the ancillary info namelists. [~~mosrs-jules:#78~~](https://code.metoffice.gov.uk/trac/jules/ticket/78) did not add the rivers ancillary to the dump stating "Care will be needed with rivers as current namelists are a mixture of grid information and actual ancillary information." Splitting the namelist into two should also mean that Rivers-standalone should no longer need information about the `jules_input_grid` reducing the dependencies of Rivers-standalone. This would also remove the grid info from `jules_rivers` leaving it for science options only.

**NB.** A complication to removing `jules_input_grid` which needs to be kept in mind, is the land fraction needs to be read in by Rivers-standalone, which is required by [mosrs-jules:#1528](https://code.metoffice.gov.uk/trac/jules/ticket/1528) (inland basin flow as an OASIS send field for LFRic-GC5), which currently prevents the JULES grid info from being removed. Adding land fraction as an allowed variable to jules_rivers_props could be explored though to remove this dependency.

[mosrs-jules:#1593 - Shared allocate routine for Rivers variables](https://code.metoffice.gov.uk/trac/jules/ticket/1593)

The allocatable arrays for Rivers need some work noting that [~~mosrs-jules:#1176~~](https://code.metoffice.gov.uk/trac/jules/ticket/1176) added these to an allocate routine, but are commented out. The number of rivers points are not calculated until the ancillaries are read so these need to be in two different routines one for those on the 2D river grid and one for those on river points.

Also it is inappropriate for all the allocatable Rivers arrays to belong to the same TYPE. Many of these allocatable arrays are only required during the initialisation. Therefore there needs to be a separate TYPE for the initialisation so they are not passed around the science code.

There is also more separation required between what is required by UM_TRIP. The fix from Dan Copsey for the Rivers component in LFRic-GC5 for ex1a [~~mosrs-jules:#1608~~](https://code.metoffice.gov.uk/trac/jules/ticket/1608), correctly allocates an array that is only actually required by UM_TRIP.

[mosrs-jules:#1609 - Add Rose stem test for Rivers standalone using LFRic-GC configuration](https://code.metoffice.gov.uk/trac/jules/ticket/1609)

Difficulties porting LFRic coupled GC5 rivers component to ex1a highlighted a need for a GC standalone configuration in Rose stem. Diving data needs to be created from the LFRic coupled app OASIS send fields.

A separate Rivers-standalone Rose stem, test rather than the existing opts file nested inside a JULES run, will also highlight when the upgrade macro will not work for **lfric_couple_rivers** and if `lsm_id != 3:` needs to be added as in [changeset:30603](https://code.metoffice.gov.uk/trac/jules/changeset/30603/main/branches/dev/maggiehendry/vn7.9_update_river_number_ancil/rose-meta/jules-standalone/version77_78.py). It will also indicate when an LFRic apps branch is required to upgrade **lfric_coupled_rivers**, as this app keeps getting left behind.