[new model] Add `ezdm` estimated with aggregated data

[GidonFrischkorn]

Complementing #64 that provides an extended implementation of the ezdm_robust that estimates RTs as a mixture of an inverse Gaussian and uniform distributions to account for potential contaminants, I would like to implement a Bayesian hierarchical implementation of the ezdm that estimates DDM parameters from aggregated data, that is mean_rt, var_rt, n_correct, and n_trials. This builds on work by Adriana F. Chávez De la Peña and Joachim Vandekerckhove: https://osf.io/yg9b5_v1/

@chenyu-psy is actually already working with the brms implementation of the likelihood and is estimating parameter recovery for this implementation.

Ideally, I would like to add a 3-par and 4-par version, the 4-par version would allow to also estimate the starting point zr by separating mean_rt and var_rt for responses to the upper and lower bound respectively. I just have to think how to best implement this without making the interface to complicated.

Steps for implementation:

• fill in model_info
• implement STAN functions
• specify check_data.ezdm
• specify check_model.ezdm
• specify bmf2bf.ezdm if necessary
• specify check_formula.ezdm
• specify configure_model.ezdm
• add function to generate initial values to allow for proper start of sampling
• specify distribution functions for the ezdm model
• check that pp_check and bridgesampling works for ezdm
• if possible: optimize sampling and speed for model estimation

[chenyu-psy]

I think the easiest way is to provide an aggregation function to users. Users only need to prepare the non-aggregated data and specify whether they want to implement the 3-par version or the 4-par version. The aggregated data can then be passed to bmm directly.

[GidonFrischkorn]

I have thought about something along the lines of an aggregate_data method for bmmodels, but this function would also have to parse the formula and aggregate the data accordingly. In principle, I like the idea, but it is also additional work and might require quite a bit of additional testing. In particular if we want to keep bmm free of tidyverse dependency, which I think will be both @venpopov and my preference. I will think about this.

For the start I will more likely provide some documentation in an article for the bmm webpage that explains how data should be aggregated for the ezdm.