Cleaning up how fluidity fields are initialised

Currently the way fluidity initialises fields is as follows with Populate_State.F90:
1.1. looks at input file at the /material_phase[#]/* level for any fields and adds these
1.2. follows a number of hardcoded paths to locations within the schema that contain field definitions
1.3. looks within each added field at the .../[scalar/vector/tensor]_field/[prognostic/diagnostic/constant]/* level for any associated fields such as diffusivity, source and absorbtion

At this point the fields are allocated and initialsed. Fluidity then needs to decide which fields require solving so the following occurs within Field_Priority_Lists.F90:
2.1 any prognostic fields at the /material_phase[#]/* level are automatically added to the solve list
2.2 a load of hacks direct fluidity to add a number of other fields to the solving list

This is all a bit messy and is very limited. As an example of the limitation, currently a lot of fields will only be found if they occur in the first material phase as the hardcoded paths have /material_phase[0]/.......
The current system requires a lot of hacking when new features are added, and the associated files are becoming increasingly messy as the options tree grows.

I propose the following:
Either, Populate_State and Field_Priority_Lists searching methods are standardised with searching algorithms that allows for wildcard characters. i.e. /material_phase[#]/... where # is taken to be any number.
Or, even better, the entire options tree is searched for fields and all of them are added. Fluidity then adds ALL prognostic fields to the solve list. Is there any reason why someone would not want populate state to add a field ion the options tree, or why a prognostic field would not be solved?

The second option would remove the need for any hacking. Care would need to be taken when adding fields within fields, where naming conventions are required.