Remove add_mean_sd if possible

[athowes]

See #241.

[athowes]

Also predict_delay_dpar?

[athowes]

Instances of using add_mean_sd outside of the definition, tests, and auto generated files:

• Used in definition of predict_delay_parameters

• R/make_hexsticker.R
  • secondary_dist <- add_mean_sd(secondary_dist)
• vignettes/epidist.Rmd
  • secondary_dist <- add_mean_sd(secondary_dist)
• vignettes/faq.Rmd
  • Notes the purpose of add_mean_sd for adding columns containing the natural scale mean and standard deviation.

[athowes]

Given the amount of things that add_mean_sd and predict_delay_parameters touch I think it might be too annoying to remove them.

[athowes]

F2F @seabbs agreed this was too much work to do before first release so will handle later.

[seabbs]

The only thing we want to do is decide if we are happy with the name predict_delay_parameters (i.e does it fit with other usage in tidybayes etc/

[athowes]

It could be add_delay_parameter_draws to be more inline with tidybayes

[seabbs]

That could be nice. it would require changing the arguments around to be newdata, fit vs fit newdata to match that pattern. That approach does become a bit clunky if calling without new data is the only caveat.

As this is the current entry point to the package I think we need to decide on this before release

[athowes]

• predict is more standard but everything else is in the package hence we support move to tidybayes approach.
• Also make sure that the outputs are the same as tidybayes
• Move to using generic approach with summaries generated from samples
• Find some way to work around the fact that we would be doing a lot of sampling by default if users put newdata = newdata
• Provide some helper to move to unique combinations of strata (can look in closed PR for example code doing this)

[athowes]

Closed in favour of #471.