Consider "time [interval?] delta" helpers

[brookslogan]

Context

• difftimes can have weird interactions with conversions and arithmetic if not carefully accounting for which functions consider their units, etc. They also don't work for yearmons. They are also slow for some operations like min().
• Lack of good time-point/interval-differencing functions seemed to be an issue influencing refactor(epi_slide, epix_slide): time types refactor #472. Potentially could be / could have been useful in Fix guess_period on datetimes, make it more precise + generic #484, Add complete.epi_df method so grouped completions don't drop epi_df… #488, revision analysis first draft #492.

Proposal

Consider implementing these helpers:

• unit_time_delta(time_type): takes a time_type, outputs an object that, added to a time_value of kind time_type, will output the next possible time_value, and which is an acceptable before argument.
  • For "daily": either 1 or as.difftime(1, units = "days")
  • For "weekly": as.difftime(1, units = "weeks")
  • For yearmon: 1
  • etc.
  • This could be mostly S3 except for "daily" vs. "weekly" Dates.
  • (Maybe tack on a "time_delta" class so we "know" that we generated these results.)
  • (Maybe this needs a "robust/messaging" version and a "fast" version if outputting 1 and 7 for daily and weekly instead of difftimes is very much faster.)
• n_periods_to_time_delta(x, time_type): outputs x * unit_time_delta(time_type) (note recycling rules should mean this works on length != 1 vectors)
• time_delta_to_n_periods(x, time_type): reverse operation, but allowing for both the numeric and difftime as inputs for "daily", whereas in n_period_to_time_delta we'd just choose to output one or the other. (Or maybe be strict and have an as_time_delta convert to the strict format.)
• {is,assert}_time_delta(x, time_type): validates whether x looks like it's an appropriate time difference. Like validate_slide_window_arg, but maybe allowing lengths other than 1, maybe allowing negatives, and maybe(??) disallowing Inf
• [time_diff(time_values, time_type) (like diff()), time_sub(time_values1, time_values2, time_type) (like -)? with time_sub maybe catching mismatched wdays for "weekly" --- again, this is almost but not quite just S3 due to "weekly" Dates, and not sure about tsibble/clock classes]

Use cases:

• before, after validation in non-Inf case
• maybe making working with guess_period, complete, etc. easier
• avoiding slow difftime operations
• [potentially supersede next_after]
• [potentially help clarify what type lag should be when we calculate it]

Discussion

@dshemetov @dsweber2 do you see these simplifying life at all?

[Originally, I was thinking of time_diff rather than time_delta, but time_delta seems more suggestive that this is something you can add to time values sensibly, while time_diff sounds like it would have to be the result of subtracting two time values, which isn't necessarily the case.]

[We should also consider n_steps instead of n_periods; might fit better for yearmon.

And maybe time_interval_delta, n_intervals?]