Updates backgrounds and resolutions in line with the MATLAB

[alexhroom]

This PR fixes #99. It additionally:

• adds a test file test_examples.py which ensures that all examples run without error (except convert_rascal, see convert_rascal example doesn't work when called programmatically #102)

I've compared the results of the new DSPC_data_background and DSPC_function_background examples to those in the MATLAB and found that they give the same results between languages.

---

• The source field has been added to the backgrounds and resolutions models. This fields contains the background parameter (for constant backgrounds), data entry (for data backgrounds), or custom file entry (for function backgrounds). The value fields (i.e., value_1 to value_5) are not required for constant backgrounds, value_1 contains an optional background_parameter used as a data offset, or contain up to five function arguments (all defined as background_parameters).
• For resolutions, the function type is still not supported, constant works in the same way as for backgrounds, but for data, neither the source nor value fields are required.
• When the background/resolution type is changed, the source and value fields should be cleared.
• In the examples and jupyter notebooks, value_1 needs to be changed to source for constant type backgrounds and resolutions.
• Use a python version of the data and function background examples to check everything works (probably worth adding them to the examples too).
• The check_indices routine needs to be modified to reflect the change of contrastBackgroundParams to be a nested list, with a variable number of inputs, and to consider a custom file entry in the case of function backgrounds.
• A routine mirroring insertDataBackgroundIntoContrastData is required, to populate the additional columns in the data files for data backgrounds.
• The output result has had backgroundParams removed from the contrastParams sub struct, with backgrounds added to the main result struct. done in Updates C++ and some unit tests #97
• ALL data files in the input problemStruct have been extended to EXACTLY six columns. Any empty columns are filled with zero values. done in Updates C++ and some unit tests #97
• The problemStruct input contrastBackgroundParams has been modified to be a nested list. The nested lists may contain between one and five indices. These are the indices of the source field (from the appropriate data struct), and from the values fields: nothing else (for constant backgrounds), a potential offset (value_1 if non-empty, for data backgrounds), or up to five function arguments (for function backgrounds).
• The field contrastBackgroundTypes has been added to problemStruct done in Updates C++ and some unit tests #97

[DrPaulSharp]

This is looking good so far. Alongside the comments, please add "backgrounds" to the output results dataclass (it's available in the C++), and then to the tests. As discussed, we should look to add the other updates to the inputs and outputs into the tests in another PR.

[DrPaulSharp]

Two things here. The matlab raises a warning when fields are cleared, so we should do the same here. Also, when I tried to change the type of a background via set_fields, I got a validation error saying the contents of the source field should be defined in data, so the field was not cleared prior to revalidation of the project.

[alexhroom]

not too sure what to do with that - ClassList.set_fields essentially creates a new object and puts it in the index of the old one, so no attributes actually 'get set'. should I refactor ClassList.set_fields to go through the proper assignment methods instead?

[DrPaulSharp]

Hmm, that refactor would cause it's own problems I think. If I recall correctly that's why I moved in that direction. You might have to write a validator that's something like set_contrast_model_field in the project and keep the "old" type as a hidden variable.

[DrPaulSharp]

That's right, I had set_fields to loop through the fields set and apply them, but ran into problems with parameters. If you change min, max and value the order in which they're applied mean that you can run into intermediate validation errors.
Is there a refactor to set_fields that could avoid this? Should we try to supress validation errors whilst we update multiple field values and revalidate the model at the end?

[DrPaulSharp]

Let me know what you think.

[DrPaulSharp]

You'd want to supress errors raised by "after" model validators, but not necessarily those from "before" model validators or field validators. Hmmm . . .

[DrPaulSharp]

What I'm thinking might be the ideal solution is to somehow turn off validate_assignment within set_fields (presumerably via a context manager) and then validate the model at the end, so any problems are caught. But then maybe biting the bullet and tuning off validation errors will work essentially as well (and definitely will be easier).