380 add forecast date recipe

[dajmcdon]

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

Added reference_date to the epi recipe. I think this is likely a better terminology. The hope is to use these for nowcasts and backcasts, so the thinking here is to make downstream computations relative to the reference in all cases. It's not specific only to forecasts.

Note: Downstream steps (such as step_adjust_latency()) can be updated in separate PRs.

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

• Resolves add forecast_date as a first-class part of the recipe object #380

[dsweber2]

Possible problem down the road: Roni is talking about switching time_value for reference_date in epidata, so we may want to too, which would lead to some confusing name collision. Probably worth going ahead with this anyways.

Just confirming, no steps/layers are currently using this right? E.g. layer_add_forecast_date?

[dajmcdon]

1. Correct. This is not currently being used by any layers or steps downstream. We can make those changes later.
2. On the reference_date name, I considered forecast_date (as in the issue name), but that seems poor relative to other non-forecasting tasks. I also thought about training_date, but the model technically isn't trained until it is fit(), so that doesn't seem right either. Maybe model_creation_date? I like reference_date because it's an important piece of information to which other methods may refer. But I'm open to alternatives.

[dsweber2]

reference_date would definitely be the best option without the collision. model_date might work; I think model_creation_date may actually be pointing to the day when the model is fit rather than the forecast date (mostly comes up in backtesting). Otherwise forecast_date seems clear enough even if it might not be an exact fit for backfill projection and nowcasting. Possibly prediction_date?