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

[brookslogan]

• Intersects with Draft and discuss naming schemes for epix_slide parameters, output #163, but the desired approach here is more settled, and any renaming decided on there could be done later.
• Relates to a similar feature we'd like in epi_slide, but this is more important + easier to implement: Add way to refer to ref_time_value within f arg to epi_slide #171
• Implementation approaches used here may be applicable to Make tidy sliding play nicely with data frame inputs #55 and vice versa.
• Interacts with Replace n in epi[x]_slide with before, after #161.

Currently, epix_slide does not make the current ref_time_value (t in the current code) available to the supplied f. This is a problem, e.g., when forecasting, where the targets for ref_time_value should be observations at ref_time_value + aheads, but there is data reporting latency, so data are only available for time_values through ref_time_value - latency. We are left with either incorrectly pretending that max(.x$time_value) is the same as ref_time_value, or making some guess or inconvenient calculation of the latency, so we can say ref_time_value = max(.x$time_value) + latency_guess_or_calculation.

Instead, we should make ref_time_value available to f. Approaches to passing:

• Metadata of .x: doesn't work, we don't provide an epi_df. [but same issue of potentially being overlooked]
• Attributes of .x: works across all forms of f, but is easily overlooked.
• Extra args/pronouns: probably the best user interface, but more complicated to implement. Notes below assume that we take this approach.

Current epi[x]_slide f functions take:

• window data
• group key (1-row tibble with values of the grouping cols)
• any additional args the user would like to pass via dots

Since epi_slide implementation might be trickier and take longer, it makes sense to make epix_slide's f functions take the following:

• window data
• group key (1-row tibble with values of the grouping cols)
• ref_time_value
• any additional args the user would like to pass via dots

(If instead we implement the corresponding epi_slide change simultaneously, we could place the ref_time_value before the group key if we felt it made more sense. I don't think one approach is dominant in this case, though. Often we group by geo, so group key followed by ref_time_value is sort of a geo value followed by sort of a time value, which seems natural given how we order epi_df columns. However, sometimes we'll group by nothing, group key followed by ref_time_value would be something useless followed by something useful, which is a bit unnatural.)

--- Implementation ideas: ---

Passing ref_time_value as a third arg when f is a function may require:

• Updating the docs to indicate that f must take 3 positional args + user's custom args.
• Ideally, validating that user's f follows this format. See Validate f function in epi[x]_slide; give better feedback if doesn't take enough args #168.
• Changing signature of comp_one_group to function(.data_group, g, <rest of the current args>) and calling f(.data_group, g, ref_time_value=t, ...).

Passing ref_time_value when f is a formula might require:

• Nothing beyond the above: maybe we would already be able to reference it in the formula as ..3 or ref_time_value
• Somehow introducing a new data pronoun or data mask (using rlang::as_data_{pronoun,mask} + other rlang stuff?), still using purrr::map_dfr.
• Some approach not using purrr::map_dfr with more freedom.

Passing ref_time_value when f is missing & ... contains summarize-like operations:

• Somehow introduce a new data pronoun or data mask?
• Change the execution environment, e.g., by setting the environment of f to a new child of itself, and binding ref_time_value within that child environment. (Careful, check whether we need to do something to copy f to avoid modifying the real f's environment.)
• [Make cur_group() work and mimic it with, e.g., cur_ref_time_value().]

[brookslogan]

This is already possible in the current interface, as epix_slide now provides computations their first input as an epi_df containing the appropriate as_of metadata. (A point of uncertainty: if we are grouping by geo_value which breaks the validity of the epi_df this might not be the case or might be brittle.) We still may want a more convenient/robust/unified interface, though.

[nmdefries]

Here are two possible ways to be able to access ref_time_value from expressions in slide ... based on the suggestions above for "[p]assing ref_time_value when f is missing & ... contains summarize-like operations":

• Add pronoun to data mask used in eval_tidy. Use like epix_slide(xx1, before = 2, slide_value = sum(time_value) - .env$ref_time_value) (.env interferes with rlang::.env but that's a detail of implementation + easy to change)
• Modify quo's env. Use like epix_slide(xx1, before = 2, slide_value = sum(time_value) - ref_time_value)

[nmdefries]

On further discussion with Logan, we'd prefer to match dplyr's handling, where cur_group() fetches the grouping variable values for the current group. We would make our own cur_*-like function for the ref time value.

There are additional dplyr functions we may want to support: cur_data() (referring to the non-grouping columns for that group) and cur_data_all() (referring to to all columns for that group) that have been deprecated, and pick() added as a replacement to cover some use cases.

This looks pretty complicated to implement and would also depend on non-exported dplyr functions and classes.

dplyr::cur_group() is a wrapper for a method of the internal dplyr::DataMask R6 class. The data mask is fetched from the environment by name and, if not found, the computation exits with an error (currently happens when trying to use cur_group() in a dots-provided slide computation). The data mask is created in each dplyr function call with settings specific to the requested computation type (via verb).

[nmdefries]

We could support use of cur_group(), etc, using the env-modifying solution above so that the interface matches dplyr but the implementation doesn't (since the backend is obfuscated anyway). Cons here are that we'd have to exhaustively implement the functionality of dplyr tidy usage instead of just inheriting it, so we could end up with syntax that only partially matches that of dplyr -- probably more confusing that just not matching dplyr at all.

[nmdefries]

On further discussion with @ryantibs, plan to implement one of the easy approaches above to make the ... act like a formula and consider revisiting the cur_group() support later.

[nmdefries]

Closed by #313 and #317.