simplify input data format

[hillalex]

• rename stan_id to pid to make the interface clearer and less implementation specific
• rename titre to value to be more in line with other seroanalytics packages and to distinguish more clearly from titre_type
• remove all model-specific variables from the input data that can be derived from other input cols, and derive them when initialising the class instead: obs_id, t_since_last_exp, t_since_min_date
• add method get_stan_data so that the user can see the arguments passed to the model (useful for debugging)
• remove unused cens_me_idx argument
• censoring indicator amended to have 3 levels: -1 is lower, 0 none, 1 upper
• add check that required data columns are present when initialising the model

Also updates the data vignette to define the input variables. The simplified input format can be seen here: https://github.com/seroanalytics/epikinetics/blob/8632ba84064a40a85c433d16c9a5d4b7e5301ee9/vignettes/data.Rmd#L17

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 97.61905% with 1 line in your changes missing coverage. Please review.

Project coverage is 97.40%. Comparing base (3960395) to head (8632ba8). Report is 9 commits behind head on main.

Files with missing lines	Patch %	Lines
R/biokinetics.R	96.00%	1 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #11 +/- ## ========================================== - Coverage 97.58% 97.40% -0.18% ========================================== Files 7 7 Lines 373 386 +13 ========================================== + Hits 364 376 +12 - Misses 9 10 +1 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[thimotei]

This all looks great to me. The only additional thing I would say it could be sensible to add would be another column for the timings of the titre dtaw and/or their last exposure. We require calendar dates currently, which in all likelihood is the format the data will be in. But I do think it could be possible for their data to already be relative. So time = 0 could be their last exposure and some positive number after that could be when their titres were taken. If colleagues wisg to use this package with already processed/published data (quite likely I think!), or publicly available data, then the data is likely to be in this relative form, instead of calendar dates. Dates are quite sensitive in terms of identifiability, so allowing for these sorts of timings would be great. I'm a little unsure how to offer either one of these options, but I do think if that is easy to do, it would be worth it! Apart from that, it all looks great.

[hillalex]

This all looks great to me. The only additional thing I would say it could be sensible to add would be another column for the timings of the titre dtaw and/or their last exposure. We require calendar dates currently, which in all likelihood is the format the data will be in. But I do think it could be possible for their data to already be relative. So time = 0 could be their last exposure and some positive number after that could be when their titres were taken. If colleagues wisg to use this package with already processed/published data (quite likely I think!), or publicly available data, then the data is likely to be in this relative form, instead of calendar dates. Dates are quite sensitive in terms of identifiability, so allowing for these sorts of timings would be great. I'm a little unsure how to offer either one of these options, but I do think if that is easy to do, it would be worth it! Apart from that, it all looks great.

This is a really helpful insight, thanks. I think I'll merge this PR and add support for relative time data on a new branch to make it easier to review.