Consider making transform_forecasts() an S3 generic

[seabbs-bot]

Summary

transform_forecasts() currently handles all forecast types through a single function with internal branching (e.g. checking for .mv_group_id to detect multivariate forecasts). As more special cases arise (like the fix in #1108 for multivariate group ID recomputation), this approach becomes harder to maintain and extend.

Proposal

Make transform_forecasts() an S3 generic with methods dispatching on the forecast class. This would allow each forecast type to handle its own transform logic cleanly, for example:

• transform_forecasts.forecast_multivariate_sample() could handle .mv_group_id recomputation natively
• transform_forecasts.forecast_quantile() (and others) could use the current default logic
• New forecast types could define their own transform behaviour without modifying the core function

Motivation

• The multivariate case already requires special handling after rbind (score() does not group by scale for forecast_multivariate_sample with transform_forecasts(append=TRUE) #1108)
• Future forecast types may need their own transform logic
• S3 dispatch is the established pattern in the package (e.g. score(), as_forecast_*())

This was opened by a bot. Please ping @seabbs for any questions.

[seabbs]

This is based on the fix to #1108 requiring some custom logic for multivariate scores. It is concievable that other targets might as well and so it might make sense to extend this to have a s3 interface like other tools.

[nikosbosse]

My intuition is that for now it's fine (if not ideal) to treat the .mv_group_id variable as a special case (thanks for fixing this!). I can see a world in which we might want to have a superclass for univariate and multivariate, but my intuition is that refactoring this to S3 doesn't gain us much and might lead to more code complexity

(see my comment here: #1154)

[seabbs]

I don't really agree to be honest. The code base has quite a few of these special cases and they are what blocks external scoring formats. That isn't the end of the world but it leads to a setting were it is hard for others to come in and support a new format or add functionality as there are multiple areas with special code.

[seabbs]

might lead to more code complexity

My take from the PR is it simplifies the code.