Get test data rework

[dsweber2]

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

make get_test_data retrieve a year by default, and make predict narrow down to the forecast_date

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

• Resolves #{issue number}

[dajmcdon]

@dsweber2 How important do you think this methodology is? Just a thought, but what if we

1. deprecate this function completely;
2. only call forecast() in examples (rather than predict());
3. Inside of forecast(), just predict the entire training data, then filter to the reference date.

[dsweber2]

if the fitting is expensive, it's probably best to predict as few days as possible (I've run into this with grf). Having something that handles that filtering is probably worthwhile.

That said, the most important part of this PR is definitely the filtering the output in the way predict runs so that it's only outputting forecasts for the right days. In practice that was the part that tripped me up more when avoiding get_test_data in exploration-tooling