Tackling relative paths in config files.

[davidorme]

Each config file can (in theory - limited to the data config and core at present) contain file paths, which could be relative. If so, those are assumed to be relative, to the referring config file. The problem is that the referring file path is lost when the configs are merged.

@alexdewar has tackled this for existing cases in #269, but it leaves a hanging issue which might affect later configs that contain paths. An example might be a path to a plant PFT file or something similar.

One way this could be tackled is to introduce an isPath = true property on appropriate JSONSchema entries. That way, the code can unambiguously identify paths that need to be made absolute using an existing canonical source of validation information.
However, I think that then requires two passes and a new Validator:

1. Merge the original config content to identify the modules and hence build the schema.
2. Run a PathResolverValidator using that schema over the individual files in self.toml_contents: this validates contents but also look for entries with isPath=true and updates the value with the absolute paths of the toml_contents keys. It doesn't add defaults though, because has to happen on the last validation pass to avoid creating clashes.
3. Now merge the updated toml_contents again and then run this through the current default filling validation.

This is a lot more complex but is also explicit about which inputs are paths.

Originally posted by @davidorme in #269 (review)

[dalonsoa]

In case it helps, this is how it is done in another piece of software we work on (towards the end): https://muse-os.readthedocs.io/en/latest/inputs/toml_primer.html

When the TOML file is read, these {cwd}, {path}, etc are replaced by the appropriate values.

[davidorme]

That's certainly a much simpler approach! It's marginally more complex for the end-user, but means that the config files have to be internally explicit about where files are relative to the config file. I suspect we'd only need {cfg_file_loc} or something similar.