Replace references to BASE_MODEL and OTHER_MODEL with MODEL_NAME list in difference recipes

### What problem does your feature request solve?

_From @ukmo-huw-lewis:_

> For discussion - propose there may be value in a further re-design here to remove explicit reference to "BASE_MODEL" and "OTHER_MODEL" in the *_difference recipe. I wonder if some of this originated from difference plots pre-dating CSET functionality to work with multiple model inputs (e.g. for overplotting N models in timeseries, histograms etc).
>
> At present, if looking to run surface_spatial_difference recipe for 2 models, I provide input variables as follows.....
cset bake -r ${path_to_recipes}/recsurface_fields/surface_spatial_difference.yaml --input-dir "${input_dir}" "${input_dir2}" --output-dir ${output_dir} ... --BASE_MODEL="${model_name}" --OTHER_MODEL="${model_name2}"
(i.e. the 2 input model paths are caught in 1 definition of input-dir but I separate out naming of BASE and OTHER.
>
> For other recipes with multiple model inputs (e.g. time series), we now call with something like....
cset bake -r ${path_to_recipes}/surface_fields/generic_surface_domain_mean_time_series.yaml --input-dir "${input_dir}" "${input_dir2}" --output-dir ${output_dir} ... --MODEL_NAME="['${model_name}', '${model_name2}']"
(i.e. MODEL_NAME is a list of inputs).
>
> I would propose adapting difference recipes to take a single MODEL_NAME input variable consistent with other recipes, and then adopt protocol of all differences as model[N] - model[0] in the list. This means e.g. analysis can be defined as first model in list and will always be identified as the 'control'.
>
> Argument against this is that spatial_difference recipe only expects 2 model inputs (i.e. does not actually loop over N models). Is the ability to do this (remove looping over BASE/OTHER combinations in workflow) desirable? For command-line use, I could envisage benefit for users to "give me differences of my N models relative to 0" for a list of models > 2.

### Describe the solution you'd like

IMO this would be a sensible change to reduce the unique behaviour of these recipes.

Currently for spatial differences the loader in the workflow is what loops over all the models and fires them off as separate recipes; each generated recipes only handles a single pair of models. Given the correspondence of one recipe to one diagnostic, I can’t see how we would handle multiple model differences in a single recipes. Line plots of bias and such could however support many models.

### Describe alternatives you've considered

Currently we have a working solution using BASE_MODEL and OTHER_MODEL, so we could leave it as is.