add holiday() special

[davidtedfordholt]

@mitchelloharawild , is there a plan for how to deal with holidays in fable? One of my favorite parts of bsts is how it treats holidays, giving a number of different types of holiday specifications (rather than Prophet's every-day-around-a-holiday-gets-its-own-dummy-variable method).

I'm thinking we will need to specify a holiday structure external to the fable workflow, to be fed into the holiday() special. It will include separate calls to the holiday() special for different types of holiday models (AddRandomWalkHoliday(), AddRegressionHoliday(), AddHierarchicalRegressionHoliday). I'm not sure if it should include different Holiday objects for different holiday creation methods (FixedDateHoliday',NthWeekdayInMonthHoliday,LastWeekdayInMonthHoliday,NamedHoliday,DateRangeHoliday). It seems like you could eventually need to have separateholiday()` calls for each combination of a model and specification. For this reason, I'm thinking that a more holistic way to specify holidays would be helpful.

This would probably also be useful elsewhere, since this and Prophet aren't the only algorithms to incorporate holidays.

[davidtedfordholt]

To grab the holiday conversation from AddNormal():

@mitchelloharawild: For holidays, I still am unsure how best to represent them and their parameters. The data approach used by prophet is pretty good, and what I'm defaulting to for now. I think holidays need an identifying key to match holidays across days/years.

I don't mind how prophet holds holidays at all (though I mind how it treats them). Given that we are operating with tsibbles, it makes sense to me to perhaps mimic the functionality of the helper functions in bsts (in the documentation for bsts::Holiday) to help people specify holidays more succinctly than prophet's method. It would be simple enough to feed those into a tsibble with the holiday name as a key and things like the window of effect or priors as measures. It could be consistent across simple models that just need the dates of holidays (it would provide, for instance, a way to specify (after a merge) a variable for switching seasonality patterns in fasster), but also provide a structure for more complex patterns (such as different priors for different holidays, or even for different instances of holidays). It could even support, I suppose, specific adjustments for holidays or for outliers that the user chooses to smooth, without wanting to change the underlying data as it would eventually be displayed with the fit or forecast.