Add way to refer to `ref_time_value` within `f` arg to `epi_slide`

[brookslogan]

See this Slack thread. See #165 for epix_slide-related discussion. Interacts with #161.

Within f, we'd like to refer to the ref_time_value we're performing the computation on.

• The workaround suggested in the slider docs doesn't quite seem to be this exactly, but rather seems to be about attaching the ref_time_value to each computation after the fact.
• It might be possible to calculate the ref_time_value from the available time_values in a time window + the align arg. However, we have to worry about gaps in the time_values and behavior near / at / beyond the edges of the range of time_values available. If it's possible, we could:
  • provide this as a helper function (but people might not notice/remember that it exists)
  • wrap the user's f in some code that performs this calculation and makes it available to the user as a metadata, an attribute, additional argument, etc. To match Vignette for supporting a user who wants to create their own epi_df and epi_archive #165, probably just a third argument to their f function.
• If there are problems due to gaps&edges in the previous approach, they might be resolved by creating a second df of time values with no gaps and extended around the edges, use hop2/slide2 instead of hop/slide; access to the second, df might make resolve some of the problematic cases for computing the ref_time_value. [On second look, this may not help; it looks like slide_index2 doesn't take two index vectors.]
• We could move away from the slider package and just use a map.
• We could try to improve the slider package.
• We could try to implement an alternative slider-like routine. (This might also benefit epi_archive performance.)

[brookslogan]

Another approach to correctly/simply recovering the ref_time_value by augmenting the original df / df group.

[nmdefries]

Link to the slider docs above is broken; an archived version is available here.

[nmdefries]

Closed by #318