refactor: epi_recipe only accepts epi_df

[dshemetov]

Checklist

Please:

• Make sure this PR is against "dev", not "main".
• Request a review from one of the current epipredict main reviewers:
  dajmcdon.
• 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).
• 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).
• 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 epi_recipe should only accept epi_df and error otherwise #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.