refactor: epi_recipe only accepts epi_df

[dshemetov]

Checklist

Please:

• [x] Make sure this PR is against "dev", not "main".
• [x] Request a review from one of the current epipredict main reviewers: dajmcdon.
• [x] Make sure to bump the version number in DESCRIPTION and NEWS.md. Always increment the patch version number (the third number), unless you are making a release PR from dev to main, in which case increment the minor version number (the second number).
• [x] Describe changes made in NEWS.md, making sure breaking changes (backwards-incompatible changes to the documented interface) are noted. Collect the changes under the next release number (e.g. if you are on 0.7.2, then write your changes under the 0.8 heading).
• [x] Consider pinning the epiprocess version in the DESCRIPTION file if
  • You anticipate breaking changes in epiprocess soon
  • You want to co-develop features in epipredict and epiprocess

Change explanations for reviewer

Only allows epi_df in epi_recipe and everything else just gives a clear error as such. Open to conversation about this, I don't know if falling back to regular recipes is useful sometimes, I haven't needed that functionality, but if it's not, then this is the behavior I prefer.

Magic GitHub syntax to mark associated Issue(s) as resolved when this is merged into the default branch

• Resolves #348

[dajmcdon]

I'm working on a more complicated refactor of this, but the short version is I don't think this is the right behaviour. An epi_recipe should be a subclass of recipe (it isn't currently) and operate on non-epi_df.

In the meantime, if you want it to warn on epi_recipe.default() that's fine, but it should produce a recipe.

A user who downloads our package shouldn't be prevented from recipe behaviour just because they started with the wrong function.

[dshemetov]

@dajmcdon Cool, I switched this change over to a warning instead.