Use `cloudpickle` or drop some aspects from training data structures

Some of the config entries look like this:

```
def get_ddm_truncnormt_config():
"""Get configuration for DDM with truncated normal non-decision time."""
return {
"name": "ddm_truncnormt",
"params": ["v", "a", "z", "mt", "st"],
"param_bounds": [
[-3.0, 0.3, 0.3, 0.05, 1e-3],
[3.0, 2.5, 0.7, 2.25, 0.5],
],
"boundary_name": "constant",
"boundary": bf.constant,
"n_params": 5,
"default_params": [0.0, 1.0, 0.5, 0.25, 1e-3],
"nchoices": 2,
"choices": [-1, 1],
"n_particles": 1,
"simulator": cssm.full_ddm_rv,
"simulator_fixed_params": {
"z_dist": functools.partial(sps.norm.rvs, loc=0, scale=0),
"v_dist": functools.partial(sps.norm.rvs, loc=0, scale=0),
"t": 0.0,
},
"simulator_param_mappings": {
"t_dist": lambda mt, st: functools.partial(
sps.truncnorm.rvs,
a=(-1) * np.divide(mt, st),
b=np.inf,
loc=mt,
scale=st,
),
},
}
```

Note that in `simulator_param_mappings`, "t_dist" is defined as a `lambda function`.
This creates problems with pickling outputs of the training data generators (which currently actively save model `metadata`, including the model-specific `config` dictionary.

The issue points to model-specific config dictionaries, especially simulator_param_mappings, and training data generators that save metadata. Start by tracing how those generators pickle their outputs and reproduce the lambda-related failure. Done means generated outputs serialize successfully, using cloudpickle or excluding the non-pickleable config aspects as the project decides.

Written by the indexing model from the issue text.